자신이 생각하는 좋은 예외 처리란?

[GIVEN53]

.

[nayonsoso]

cf. 좋코나코에도 나오는 내용

[gyungchan-jo]

좋은 예외 처리란:

1. 해당 상황이 발생한 이유를 명확하게 설명해야 합니다. 각 예외는 적절한 메시지와 함께 생성되어야 하며, 이를 통해 디버깅과 로깅을 향상시킬 수 있습니다.
2. 예외의 성격과 상황에 맞는 적절한 예외 타입을 선택하여 사용해야 합니다.
3. 프로젝트의 특정 상황에 대응하기 위해 사용자 정의 예외 클래스를 작성하는 것이 좋습니다.

그리고 오류 전달 방법에는 검사 예외와 비검사 예외가 있는데, 대부분의 오류 처리가 코드의 상위 계층에서 이루어질 수 있다.
그래서 많은 수의 catch-throw 블록을 필요로하는 검사 예외를 사용하는 것이 아니라, 비검사 예외를 사용하여 코드 구조를 개선하는 것이 좋다 생각합니다.

[le2sky]

문제가 발생하면 신속하게 실패하는 것이 좋고, 발생한 문제를 복구할 수 없는 경우에는 요란하게 실패하는 것이 바람직합니다.
신속하게 실패하지 않는 경우에는, 문제의 실제 발생 지점으로부터 멀리 떨어진 코드에서 발견되기 때문에 추적이 어려울 수 있습니다.
요란하게 실패하지 않는 경우에는, 문제가 발생하는데도 불구하고 아무도 모르는 상황을 만들어낼 수 있습니다.

복구는 발생한 문제를 정상 상태로 돌려놓는 것을 의미하며, 호출하는 쪽에서는 복구 작업이 일어났는지 알 수 없습니다.
회피는 내부에서 처리하지 않고 호출하는 쪽에서 처리할 수 있도록 하는 방식을 의미하며, 내부에서는 어떻게 처리되는지 알 수 없습니다.
전환은 회피와 비슷하지만, 의도를 들어낼 수 있다는 점이 다릅니다. 실패하면 외부에서 처리하되 추상화 레벨에 맞게 실패한 이유를 변경하는 방법입니다.
무시는 아무런 처리를 하지 않는 방식을 의미하며, 내부에서도 조치하지 않고 외부에서도 문제가 발생했다는 사실을 알 수 없습니다.

의도가 담기지 않은 회피와 무시는 가능한 사용하지 않는 것이 좋지만, 의도가 담겼다면 훌륭한 방법이 될 수 있습니다.
좋은 예외 처리를 하기 위해서는 의도에 맞게 잘 처리하는 것이 중요하고, 잘 처리하기 위해서는 예외 처리에 대한 이해와 경험이 필요합니다.
예외 처리를 할 때 마다 의식적으로 어떠한 의도를 담을지 고민하며 작성하면 좋은 예외 처리를 할 수 있습니다.

[GIVEN53]

오류를 숨기지 않고 신속하고 요란하게 알리는 것
신속하다: 오류 발생 지점과 가까운 곳에서 예외 던짐
요란하다: 오류 발생했다고 명백하게 알림

숨길 경우
어디서 발생한 오류인지 모름
다른 개발자가 인지못함