1. 오류를 나타낼 때는 오류코드 냅다 던지지 말고 예외를 던지자
에러코드 ~~ 이면 ~~ 로 처리한다 전개보다는
오류가 발생한 곳에서 예외를 던진다.
별도의 처리가 따로 필요하다면 checked exception 처리하고,
그렇게 할 생각이 없다면 메서드 선언부에 throws Exception 이라도 둘러주자.
(사실 try catch 제외하면 나 이거 제일 좋아함)
try -> catch 를 통해 실행문을 감싸고, 예외를 처리할 수 있는 곳에서 catch
2. 특별한 경우가 아니라면, 에러클래스를 상속하여 하위클래스를 쓰잘데기 없이 또 만들지 말 것.
unchecked throwable 은 RuntimeException의 하위 클래스로 만들자.
쓸데없이 throwable을 정의해서 만들 수도 있지만 굳이 그래야할까?
특정 메소드에서 정해버리면 그 상위 단계들에서도 정하고 던지게 해야 하는데 OCP(개방폐쇄원칙)에도 위배
3. 예외처리 할 때 메시지에 신경쓰기
원인과 위치를 찾기 쉽도록 전후 상황, 실패한 연산 이름과 유형 등을 상세하게 서술하기
/ 0 이라든가, null이 들어왔다든가 등등.
로그만 찍어갖고는 그걸 언제 다 까볼건데?
checked exception들은 따로 클래스로 묶어서 예외를 감싸는 방법도 고려해볼 수 있겠음.
4. 예외처리 유의사항
getOrElse - 예외 대신 기본값을 리턴(null이 아닌 / 도메인에 맞는)
getOrElseThrow - null 대신 기본값을 정할 수 없다면 그냥 예외처리
그러나..
숫자 많이 다루는 업무 특성상 약간 변태처럼 null체크에 집착할 수밖에 없는데
널이 나온다고 돌던 배치 프로그램을 전부 중단하고 예외처리 던져버릴 수는 없는거라... 이것도 참 난감하군
메소드가 특별히 요구하지 않는한, null값을 메소드의 파라미터로 넘기지 않도록 유의하기. 빈 값 주는 게 더 별로임.
'study > Java' 카테고리의 다른 글
클린코드(Clean Code) 9장 - 단위테스트 (0) | 2022.09.18 |
---|---|
클린코드(Clean code) 8장 - 경계 (0) | 2022.09.14 |
클린코드(Clean code) 6장 - 객체와 자료 구조 (0) | 2022.09.11 |
클린코드(Clean code) 5장 - 형식 맞추기 (0) | 2022.09.10 |
클린코드(Clean code) 4장 - 주석 (0) | 2022.09.09 |
댓글