토비의 스프링 - 1권 4장 예외

catch문은 조치를 위한 자리다

try catch문에서 자주보는 예외처리에서 cath문은 예외가 발생했을때 적절한 조치가 필요한 자리다 적절하게 복구가 되던지 

아니면 작업을 중단시키고 개발자에게 통보 되어야한다 단순히 catch문으로 에러를 잡은 후 에러문구 노출인 e.printStackTrace();는 예외를 처리한 것으로 판단하기 어렵다 오히려 어디서 예외가 발생했는지 알수없게하는 예외 블랙홀이 가능성이 될 확률이 높다.

또한 아무 생각 없이 반복적으로 throw Exeption을 붙이는 것 또한 좋지 못하다 해당 작업에서 어떤 예외가 발생 할지 최대한 범위를 좁히는 것이 좋다.

사실 예외중에 일부러 에러를 발생시키는 부분에 대해서는 개발자들 사이에서 이견이 많다고 한다.

예외를 바로 처리하지않고 예외 클래스를 만드는 것 자체가 오류로 판단하기 때문이다.

예외의 두가지 타입

1. 체크 예외 :

명시적 예외처리이며 Exception의 서브 클래스중 RuntimeException을 제외하여 상속 받은 예외

 

2. 언체크 예외 :

RuntimeException을 상속한 예외로 명시적인 예외를 강제하지 않는다 catch로 잡을 필요가 없고 throw하면된다 오브젝트 할당이나 변수값 null등의 nullpoint illegargument 등이 있다.

 

에러 처리 기법

1. 예외 처리 회피 :

예외는 복구하거나 혹은 다른 오브젝트에 책임을 지게하거나 설정해야한다.

2. 낙관적인 예외 처리 기법 :

시스템 레벨에서 처리해줄것이라 생각하는 기법

 

3. 비관적인 예외 처리 기법 :

자체로직으로 의도적 발생시켜 catch문에서 무엇인가 조치하는 예외 기법이다.

요약

서버의 아웃 오브 메모리 또는 네트워크 등의 에러로 catch를 잡아도 아무런 대응 방안이 없다.

이러한 에러는 해결을 할 수 없기 때문에 잡을 이유가 크게 없다.

자주 발생하는 sqlException은 catch에서 처리할 수 없는 로직일 확률이 높기때문에 언체크로 두고 개발자가 빨리파악하고 수정하는 방법 밖에 없다.

 

예외처리에서 catch문은 무조건 설정하는 것이 아닌 처리 할 수 있을때 설정 하는 것이다.

물론 클라이언트에서는 화면에서는 오류 코드가 노출 되지않도록 해야 한다.