지난번에 글을 쓸때는, 예상했던 것보다 시간이 많이 필요했는데, 어느덧 이른 6시, 출근할 시간이 되어서 이야기를 다 마무리 못하고 펜을 집어 넣어야만 했다.

지난번 글에서는 자바에서 Exception Handling이 어떻게 생성되고, 호출하는 코드로 어떻게 알려주게 되는지를 간략하게 이야기 하였다. (뭐 간략하다고 했지만, 이미 알고 있는 내용들이 었을 것이다.)
그리고 RuntimeException의 유형의 예외들은 컴파일러에서 신경을 쓰지 않기 때문에, 반드시 Try-Catch로 블록을 만들어 줄 필요가 없다는 것을 이야기 했다. (이 경우는 개발자가 코드상에서 해결해 주어야 한다는 것도 같이 이야기 했다.)

마지막으로, Eclipse와 같은 IDE에서 자동으로 생성되는 예외 처리 코드에 관해서도 이야기 했는데, 자동으로 생성되는 메커니즘도 이야기 했었는데, 더불어서 사용할 때 주의해야 할 것은 자동으로 생성된 코드로 인해서 예외처리가 끝났다고 착각하지 말아야 한다는 것이다. 실제 예외에 대해서 프로그램 또는 클래스에서 예외처리에 대한 코드가 들어가야하고, 이를 로그로 저장하거나 화면에 뿌려줄때는 좀더 사용자 친화적인 내용으로 저장하고, 보여주어야 추후에 유지보수하기 쉽다.

오늘은 이전에 시간이 모자라서 하지 못했던 이야기를 하려고 한다.
일반적으로 try-catch블럭의 사용을 잘 알고 있을 것이고, 더불어서 finally의 사용 또한 잘 알고 있을 거라 생각한다. 호출해야 할 코드는 try블록에다 정의하고 만약 예외가 호풀되면, 이를 제어하기 위해서 catch 블록에서 정의한 코드가 호출되고, 그리고 다시 코드가 실행된다. (try 블록에서 예외가 발생했던 코드 라인 이후는 호출이 되지 않는다.)

만약, 여기에 finally구문을 사용할 경우가 있는데, 아시다 시피 이는 try 또는 catch블록에 정의된 내용이 실행과 상관없이 정의되어 있다면 만드시 실횅되도록 정의되어 있다.
이 경우에 try 또는 catch구문에 return 문이 있다면 어떻게 될까?
try 또는 catch 블록에 return 문이 있다면, 일단 finally구문에 정의된 소소 코드들을 실행하고 나서 다시 return문으로 돌아 온다는 점에 유의 해야 한다.

예외도 객체이기 때문에 이를 상속받아서 새로운 예외들을 만들수 있다. 때문에 예외처리시에 아래와 같이 모든 예외를 한번에 다 잡을 수도 있지만, 이는 바람직하지 않다. 이전글에서 설명한 것처럼 어떤 메소드를 호출할때 어떤 메소드가 호출될 것인지가 클래스와 메소드 정의서가 정의된 문서를 보면 확인할 수 있다.

try {
      runAnyCode();
} catch (Exception ex) {
     recoveryCode();
}

위의 코드의 경우는 예외느 다 잡을수 있을지 모르지만, 어떤식으로 예외를 관리할지는 전혀 알수 없다. (물론 때에 따라서는 상위의 예외로 부터 하위의 것을 모두 잡는 것이 유용할 수도 있다. 따라서 유의해서 사용해야 한다.) 꼭 필요한 경우가 아니라면, 예외별로 잘 정의해서 사용해야 한다. 아래는 예이다.

try {
      runAnyCode();
} catch (anyCodeException aex) {
     recoveryCode();
}

마지막으로 정말 중요한 것은, 예외 처리에서 순서가 있다는 것이다.
그렇기 때문에 다중으로 예외를 선언한 경우에 주의가 필요하다. 만약 어떤 예외를 상속 받아서 새로운 Exception 들을 만들었다면, 상속 받았던 에외들을 먼저 선언해 주어야 한다. 그렇지 않다면, 원하지 안는 결과를 얻을 수도 있다.
왜냐하면, JVM 에서는 첫번째 Catch블록에서 부터 호출된 예외를 처리한 Catch블럭을 찾아 내려오기 때문이다. 만약 가능한 예외 블록이 있다면, 비교를 멈추고 catch블록에 정의된 예외처리 코드들을 실행하게 된다.
따라서 만약에 첫번째 catch블록이 catch(Exception ex)라고 정의되어 있다면, 컴파일러는 다른 catch블록이 전혀 필요 없다고 생각할 것이다. (왜냐하면 이외의 catch 블록의 코드는 전혀 실행되지 않을 것이기 때문이다.) 
아래 코드에서 어떤 코드는 실행되지 않을 까요? 
try {
      runAnyCode();
} catch (Exception ex) {
     recoveryCode();
} catch (anyCodeException aex) {
     recoveryCodeNotRun();
}

내가 하고 싶은 이야기는 사실 마지막에 이야기 하고 싶은 내용이었다. Exception에도 순서가 있고 진행되는 방향이 있다. 하지만 이를 모르고서 코드를 작성한다면 의미없는 코드를 생성하게 되고 결국은 나중에 코드의 문제를 찾는데 많은 시간을 들여야 한다는 것이다. 가장 기본 적인 이야기지만 간과하는 부분이기도 해서 이야기 하고 싶었다.

이전에 인도 개발자들이 만들어 낸 코드들 분석하면서, 내가 경험했던 것들인데, 예외 처리를 했기 때문에 문제가 없을 거라는 막연한 믿음보다는 예외처리시에 필요한 코드상에서 처리해 부분(RuntimeException)들과 catch문을 사용할 때도 우선 순위를 생각하면서 정의할 것등을 반드시 숙지해야한다.
무엇보다도 가장 판단하기 어려눈 것은 try-catch문을 아무 생각 없이 중첩해서 사용하는 경우인데, 이 경우는 가독성도 떨어지지만, 예외 처리 코드를 분석하기 매우 어렵기 때무에 되도록이면 피해야 한다.




Posted by 행복상자
일반적으로 자바에서는 C++와 마찬하지로 try catch 구문을 사용하여 예외 처리(exception handling)을 하게 되어 있다. 하지만, 개발자들이 잘 알지 못하고 사용한다면, 양날의 검처럼 작용할 수 도 있고, 유익하지 않을 수도 있다.

작년과 올 상반기까지 회의 연구소 인력들과 같이 협업하는 프로젝트가 있어서, 설계와 구현을 이들과 일정 부분 코드를 나누어서 진행하였다.
일반적으로 인도쪽 개발자들은 인건비가 싸고, 개인적인 개발 능력이 뛰어 나다고 알려져 있는데, 근 1년 이상 협업을 하면서 느낀점은 사실은 그렇지 않을 수도 있다는 것이다. 일반적으로 인도는 Windows 애플리케이션 개발과 C/C++ 을 잘사용하는 개발자들은 많기 때문에 쉽게 구할수 있기 때문에 그 중에는 능력있는 개발자들이 많이 있을수 있다. 하지만 Java라는 언어를 알고 있는 개발자는 적고, 그 중에서 웹과 J2EE의 영역들을 이해할 수 있는 개발자는 지극히 드물다. 따라서 실력있는 개발자를 Java쪽에서는 찾기가 매우 힘들다.

이야기가 길어졌는데, 인도 개발자들이 작성한 코드를 우리쪽에서 Prevent라는 툴을 이용하여 정적분석을 시켰는데, 몇가지 Critical한 내용들이 보고되었다. 그래서 이를 인도 개발자에게 코드 리뷰를 하고 수정하도록 했는데, 정적분석 수행시 마다, 동일한 위험요인에 대해 지속적으로 검출되었다. 개발자는 매번 확인하고 수정했고 코드에는 예외처리가 다 되어 있어서, 문제가 있을 수 없다고 했는데도 툴은 지속적으로 문제점을 검출하고 있었다. 그래서 결국은 내가 그들이 작성한 코드를 분석하고 리뷰를 하였는데, 여러 면에서 놀라야만 했다.
이들은 자바 프로그래밍에 대한 초보자들이었다. 거의 C/C++ 방식의 코딩과 Excepion 처리를 통한 회피에만 집중하고 있었다. 너무나도 복잡하고 다중적인 예외처리 문을 사용하는 것에 대해서 혀를 내둘러야 했다. 일단 좋은 코드는 보기도 좋아야 하는데, 무슨일을 하고 무엇을 말하려고 하는지 알수 없을 정도록 예외 처리문을 반복적으로 사용하였다. 어떤 식으로든 예외를 처리하고 나오도록 코드는 되어 있지만, 몇가지 간과한 점들이 있었는데, 그 중에 중요한 점은 예외 처리에도 순서가 있다는 것이다.

예외 처리(exception handling)시에도 지켜주어야할 순서거 있고, 이를 잘못하면 원하는 결과를 얻을 수 없을 뿐더러, 코드가 복잡해 진다.

일반적으로 예외를 처리한다는 것은 어떤 메소드를 호출하고 실행할 때, 그 메소드가 어떤식으로 동작할지 아로 있어야 한다. 이는 메소드가 결과값을 반환할 뿐만 아니라, 어떠한 경우에 예외를 호출할지를 정확히 알고 있어야 한다. 

예를 들어 "java.lang.ClassLoader"라는 클래스를 사용하려고 한다면, 이 API는 아래와 같이 정의된다.

loadClass

public Class <? > loadClass(String  name)
                   throws ClassNotFoundException 
지정된바이너리명을 가지는 클래스를 로드합니다. 이 메소드는,loadClass(String, boolean) 메소드와 같은 방법으로 클래스를 검색합니다. Java 가상 머신이 이 메소드를 호출해, 클래스 참조를 해결합니다. 이 메소드를 호출하는 것은,loadClass(name, false) 를 호출하는 것에 상당합니다.

파라미터:
name - 클래스의바이너리명
반환값:
결과적으로 얻을 수 있는 Class 객체
예외:
ClassNotFoundException - 클래스가 발견되지 않았던 경우

위처럼 정의되는 API는 실행해서 결과값을 정상적으로 반환하고, 만약 실행 중에 문제가 될 경우, 이를 어떤식으로 호출하는 메소드에 알려 줄지를 정의하고 있는 경우이다. 위의 예제는 ClassLoder 클래스를 실행시 클래스가 발견되지 않는 경우에 "ClassNotFoundException"이 호출된다.
따라서 위와 같은 명세를 정확히 개발자가 알고 있어야 메소드 호출시에 어떻게 동작할지를 예측하고 코드를 작성할 수 있다.

try-catch 구문을 사용하는 것은 호출할 메소드에서 예외를 발생시킬수 있다는 것을 알고, 이를 컴파일러에 알려주는 역할을 하는 것이다. 그리고 이때 호출되는 exception도 객체로 정의되어 사용되어 진다.
그렇다면, Exception 객체는 어디에서 정의 되는 것일까? 이 객체는 개발자가 사용하고자 하는 메소드에서 정의되게 되는데, 메소드에서 "throws"구문을 찾으면 된다. 이렇게 정의된 예외는 예외가 정의된 메소드를 를 호출하는 곳으로 던져지게 된다.

자바 개발자들이 많이 사용하는 Eclipse와 같은 IDE에서는 어떤 메소드를 호출할 때 자동으로 try-catch문으로 호출하는 메소드를 감싸주는 기능을 자주 사용하게 된다. 이는 내부적으로 호출되는 메소드 내부에 "throw"구문이 호출된다는 것을 IDE툴이 알고 있기 때문이다.

한가지 더 나아가서, 자동으로 생성하는 예외코드는 보통 아래의 예외 같은 형태로 IDE상에 추가된다.
java.io.File file = new java.io.File("c:\\test.txt");
try{
    file.getCanonicalFile();
catch (IOException e) {
    e.printStackTrace();
}

한가지 주위해야 하는 것은 위와 같이 "e.pringStackTrace()"를 툴에서 자동으로 생성해 주었다고, 예외 처리가 모두 끝나는 것이 아니다. 
1. 위에서 처리해야할 예외에 대한 후 작업이 있다면 코드를 생성해 주어야 한다.
   ==> 이것은 대부분의 개발자들이 잘하고 있다.
2. 위의 예외를 Log에 남길지를 결정해야 한다. 
   ==> 이 부분은 개발자와 개발팀 내부의 결정에 따라서 정리하면 된다.
3. 위와 같은  형태가 아니라, 개발자가 나중에 알수 있는 형태의 메시지 형태로 재 정의 해서
    메시지를 뿌려 주어야 한다.
   ==> 결국은 개발자가 어떤 상황에서 에러가 발생했는지를 알수 있어야 하고, 이를 로그로
        남겨야 후처리에 도움이 될 것이다.
위와 같이 간략하게 3가지로 정리하였지만, 대부분(?)의 개발자들이 IDE툴에서 제공하는 원형 그대로의 메시지를 사용한다. Log를 남길때도 "e.printStackTrace()"의 원형 그대로 남기는데, 어떤 경우에 예외가 호출되었는지에 대한 정보를 남겨주어야 제대로 된 예외처리라 할 수 있다.

컴파일러에서는 RuntimeException과 특수한 유형을 제외한 Exception을 관리하게 되는데, RuntimeException을 확장한 예외 클래스는 그냥 모두 통과된다. (자동으로 무시된다는 의미)
이는 대부분의 RuntmeException들은 실행 중에 어떤 조건에 문제가 생기는 경우보다는 코드의 논리에 예측 및 예방할수 없는방시으로 문제가 생기는 경우에 발생하기 때문이다.
예를 들면, 배열에서 인덱스의 범위를 벗어났는지에 대해서는 배열의 길이(Size 또는 Length)를 이용해서 확인하고 방지할 수 있다.

예외 처리에 대해서, 이야기 했는데 아직 내가 하고 싶은 이야기에는 도달하지 못했다. 이는 다음에 계속 이어서 말하려 한다.

Posted by 행복상자