안녕하세요, 45번째 시간입니다. 새로운 장인 예외처리에 도달했군요! 마지막 장이기도 합니다.

이번 챕터는 메서드가 실패했음을 알리기 위해서 예외를 이용하라, 입니다. 사실, 메서드가 실패했는데, 에러만을 던지는 것보다 그것을 프로그램에게 알려서 조치를 취하게 하는게 좋다, 같은 건 어느정도 당연한 생각입니다만, 과연 그런 내용일지?

설명

1. 메서드가 요청된 작업을 제대로 수행할 수 없는 경우 예외를 발생시켜 실패가 발생했음을 알려야 한다.

2. 오류 코드를 사용하는 방법은 좋지 않은 것이, 사용자가 이를 쉽게 무시할 수 있고, 오류 코드를 검사하고 이를 활용하는 코드 때문에 정상적인 실행 흐름을 혼돈스럽게 만들고, 핵심 논리를 흐리기 때문이다.

3. 또한 실행흐름을 제어하는 메커니즘으로 예외를 사용하는 것은 좋지 않다.

4. 그 이유는, 예외 자체가 비용이 비싸고, 이에 대응하는 코드를 작성하는 것이 어렵기 때문에, 애초부터 예외가 발생하지 않도록 최소화 하는 것이 중요하다는 것이다.

5. 따라서 개발자가 try/catch 블록을 작성하지 않고도 정상적으로 메서드가 수행될 수 있는지를 확인할 수 있는 API를 함께 제공하는 것이 좋다.

6. 또한 오류를 보고하는 방식 보다 예외를 던지는 것이 좋은 이유는, 예외는 클래스 타입이므로, 개발자가 자신만의 예외 타입을 파생시켜 오류에 대한 정보를 세밀하게 전달할 수 있는 반면, 보고하는 방식은 오류의 발생 여부를 제외한 추가정보는 얻기 힘들기 때문이다.

7. 예외상황이 발생되면 이를 프로그램에서 무시하기는 어렵다. 적절한 Catch문으로 예외를 잡아내지 못하면 프로그램이 종료된다는 문제가 있고, 또, 이를 그냥 무시해버리면 데이터가 손상된 상태로 응용프로그램이 실행될 것인데, 정상적인 실행이 될리 만무하기 때문이다. 따라서, 모든 상황을 예외로 처리할 필요없이, 그 중요도와 흐름에 따라서 정하는 것이 좋다.

8. 어떠한 경우에는 예외를 발생시키는 테스트를 할 수도 있는데, 이를 처리하기 이전에, 예외상황을 검사할 수 있는 메서드와 함께 사용하면 좋다. 이를 사용하면 예외가 발생하지 않을 경우 아예 진행이 안되게 진행 흐름을 조절할 수 있고, 예기치 못한 상황이 발생할 확률이 적어지기 때문이다. 이렇게 예외를 줄여가다보면 예외가 잡아먹는 비용을 아낄 수가 있어, 성능 저하 문제에 대해 조금 더 자유로워진다.

결론

결론적으로, 특정 메서드가 작업을 온전히 완료할 수 없을 경우, 예외를 발생시킬지를 결정하는 것은 개발자의 몫이나, 오류가 발생했을 때는 항상 예외를 발생시키도록 코드를 작성하는 것이 좋다. ㅡ 이를 통해 예외를 잡아내거나 성능 저하를 피할 방법을 찾을 수도 있으니까! ㅡ 다만, 예외는 일반적인 흐름 제어 메커니즘으로 생각해서도 안되고 사용해서도 안된다. 그리고 요청된 작업이 성공적으로 수행될 수 있을지를 사전에 검사할 수 있는 메서드를 같이 제공하는 것이 좋다.