보통 웹개발에서 생각하는 오류는 네트워크나 사용자쪽 문제라서 많이들 트라이 캐치로 오류를 잡는거라고 생각합니다
(이건 외부 환경에서 어떤 조건이 들어올지 알 수 없기 때문에 특별한 방법이 없는거같습니다)
그러나 개발자와 개발자 사이에서 서로 만들어둔 함수를 호출하면서 개발하고 버그를 잡을 때는
assert만큼 비용이 적고 디버깅도 잘 되는 수단이 없다고 생각합니다
테스트코드처럼 작성에 추가비용이 많이 필요한 것도 아니고
내가 한 가정이 제대로 작동하는지 코드에 박아두고 개발단계에서 이상하게 호출하는 동료가 있으면 바로 검증이 되거든요
아무튼 둘 다 섞어서 쓰는게 맞기는 한데
개발환경에 따라서 어느 것이 더 사용되느냐 차이가 나고 개발이 모두 웹개발은 아니기 때문에
모든 오류를 예외처리로 던질 필요는 없는 것 같습니다
assertion는 try-catch랑 딱히 관련이 없는데
옛날에 스프링 작업중에 함수 호출에 대한 모든 예외 케이스에 대해 if문으로 얼리리턴 throw 하는 코드를 본 적이 있습니다. 이런 경우라면 assert를 쓰는게 좋다고 생각합니다. 그리고 어썰트와 트라이 캐치를 통한 예외 처리가 어떤 면에서 관련이 없는건지 알려주시면 좋겠습니다. 저도 사용 용도나 목적 등에서 별로 관련이 있어선 안된다고 생각하거든요
님이 하는거 보면, 디테일이 좀 떨어지는 느낌. if문으로 얼리리턴이야 할 수 있지. 예를 들어, 공개 인터페이스는 사용자가 어떤 값을 입력할 지 알 수 없으니 인자를 검증하기 위해 assertion보다 if로 처리하는게 낫지. 개발할때 뿐만 아니라 프러덕션에서도 잡아야하니까. 복잡하면 둘다 쓰는경우도 있고. 내부 인터페이스(private)은 assertion이 낫고.
트라이 캐치는 예외가 발생했을때 처리하는 거고 어썰션은 프로그래머가 세운 가정을 코드로 직접 명시하는건데, 그것을 개발 과정에서 최대한 처리해서 맞는지 확인하고 프러덕션까진 끌고가지 않는거지.
트라이 캐치: 어떤 일이 일어날지 모르지만 이 코드에서 문제가 발생하면 예외가 생깁니다 그러니까 처리해야함 assertion: 내가 세운 가정은 이거고, 이건 깨지면 문제가 있는겁니다.
제 설명에 디테일이 부족한 것은 맞는데 저도 말씀해주신 부분에 지극히 동감하고 있어서 뭐라고 더 드릴 말씀이 없습니다. 그리고 앞서 제가 말씀드린 케이스를 다시 생각해봐도, 사용자 입력에 대한 처리가 아니라 비즈니스 로직 연산을 위해 프라이빗 메소드로 분리시켜놓은 케이스라서 assert가 더 맞는거같습니다.
서로 같은 방향을 본건데 표현차이가 있었나봄
제가 개떡같이 말했나봅니다. 아무튼 사람들이 열린 마음으로 여러가지 방법을 배워두고 잘 활용할 수 있으면 좋겠습니다
assertion이 깨진건 복구 불가능한 에러고 try-catch는 아니잖음 그 차이를 생각해야지
assert가 해야할 일들이 웹에서는 jest로 넘어간것도 좀 있다고 봄
아 아랫글 첨언이었구나 ㅋㅋ 나도 예측 가능한(Production에서 발생하면 안되는 상황의) 바운더리 테스트는 assert로 하는게 맞다고 봄
If else
try-catch: 유저가 뭔가 잘못함 assert: 개발자가 뭔가 잘못함