일반적으로 자바에서는 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 행복상자