history

(1) 예외를 잡았다면 반드시 처리해야 한다.

  - 하지만 그 예외가 에러라면? 저라면 시스템 환경을 개선하고 처리하지 않겠습니다.

  - 시스템을 종료하거나 혹은 예외에 대한 상황을 처리 할 수 있다.

(2) 로그를 반드시 남겨야 한다.

 - 예외가 어떤 예외인지 구체적으로 명료하게 로그로 남겨야 한다.  

 - 예외가 발생한 원인, 시스템의 정보, 이외 반드시 판단 가능한 메세지.

 - 로그는 프로그래머가 처리 상황을 판단 할 수 있는 구체적인 증거입니다. 특히 서버 개발자에겐..

(3) 새로운 예외를 던질 수 있다.

 - 세세한 예외를 더 추상화하여 던진 경우이다.  

 - 예외 원인에 대한 정보가 부족할 경우 새로운 예외를 던짐으로써, 구체적인 정보를 얻을 수 있다.

(4) 예외 무시

 - 큰 이상이 없다고 판단되면 예외를 무시할 수 있다.

 - 좋은 방법은 아니다.

4. 예외처리 패턴

(1) 예외복구

try{
 ....
}
catch(SQLException e) {  
   
    logger.error("Insert Query Failed . Method Name '' , User id is blar...");
    e.printstackTrace();
}finnally{

..
예외에 대한 처리작업을 수행해야 할 것이다.
doAnything();
}

 => 예외복구에 대해 반드시 인지해야 되는 점은 프로그램이 정상적으로 작동하게끔 수행해야 한다는 것이다. 비록 예외가 발생되었어도 프로그램 로직에 의해 시스템이 종료 혹은 계속해서 수행할 수 있어야 할 것이다.

(2) 예외회피

  public void process() throws Exception {

......
}

  => 예외를 메소드에 정의함으로써, 예외에 대한 처리를 수행하지 않고 있다. 또한 추상클래스인 Exception을 예외로 던졌기 때문에, 구체적인 예외에 대한 처리가 부족하다. 즉, 좀 더 세부적인 예외를 잡아먹고 있다. 예외회피를 불가피하게 해야할 경우를 제외한다면, 신중하게 선택해야 할 것이다.

(3) 예외전환

try{
 ....
}
catch(Exception e) {  
 
... 추상 Exception에 대한 정보 또한 로그로 남기면 좋을 것이다..  
  throws New SQLException("Exception is SQLException. Insert Query Failed . Method Name '' , User id is blar...");
} 

 => 예외를 중첩하여 사용하여 어떤 예외에 대한 처리인지 분명하게 처리하였다. 만일 복구가 불가능 한 예외에 대한 처리라면 RuntimeException으로 전환하여 다른 예외에 대해 일일히 처리하지 않게끔 할 수 있다. 

예외에 대해 정리하면서 느낀 생각은, 개발자라면 항상 예외에 대해 염두하고 있어야 한다는 점입니다.  (특히 나같은 초급개발자라면..)

예외를 잡았다면 반드시 처리해야 할 것이며, 예외 상황에 대한 충분한 로그를 남겨야 할 것입니다. 충분히 예외상황에 대해 인지하고 처리를 했다면 유지보수 측면에서 혹은 협업단계에서 효율적으로 시스템을 개선할 수 있을 것입니다.

=> 예외의 목적은 시스템 개선이다!!