HAMA 블로그

ClassNotFoundException :   

public class Test1
{
}
public class Test 

{
   public static void main(String[] args)

   {
        Test1 = new Test1();    
    }

}

번외 :  JAVA 와 WAS 의 클래스 로딩 차이 

Java에서 클래스로더가 클래스나 리소스를 찾을 땐 부모 클래스로더에게 우선 이를 위임하게 된다. 그래서 부모 클래스로더가 해당 클래스나 리소스를 찾을 수 없게되면 자신이 직접 해당 클래스나 리소스를 찾는 형태로 동작하게 된다. 아래는 이와 관려련하여 Java 7의 API문서에서 발췌한 내용이다.

클래스로더가 복수개 존재할 때 공통으로 사용되는 클래스나 리소스들을 모두 각자 로딩한다면 해당 자원들을 중복되게 로딩함으로써 JVM의 permanent generation를 낭비하게 된다. 하지만 부모 클래스로더에서 해당 자원들을 먼저 찾는 방식으로 동작할 경우 복수개 클래스로더의 부모가 모두 같을 경우 부모에 로드된 자원을 함께 사용하게 되므로 자원의 낭비를 막을 수 있다. 이러한 방식의 클래스로딩 메커니즘을 parent-first / child-last 방식이라고 명명하도록 하겠다.

하지만 WAS에서는 parent-first / child-last 방식을 사용하지 않는다.

(이미지 출처: Tomcat 클래스로더 How-to)

대표적은 WAS인 Tomcat의 클래스로더 계층구조는 위의 그림과 같다. 만약 WAS에서 Java와 같은 parent-first / child-last 방식의 클래스로딩 메커니즘을 사용할 경우 각각의 웹앱들은 Common 클래스로더에서 로딩된 클래스를 함께 사용하게 된다. 즉, WAS의 lib 폴더에 존재하는 클래스들을 모든 웹앱에서 함께 사용하게 되어버린다.

웹앱 개발 시에 A라는 라이브러리의 최신 버전인 2.0 버전을 사용했다고 하자. 개발과 검증을 모두 완료하고 해당 웹앱을 WAS에 배포했는데 만약 Common 클래스로더에 이미 A라는 라이브러리의 1.0 버전이 로딩되어 있다면 어떻게 될 것인가? 1.0과 2.0의 클래스 명(패키지 경로 포함)이 같고 기능이 바뀌었다면 2.0기반에서 작업된 웹앱은 제대로 동작하지 않을 것이다. 이와 같은 문제가 발생할 수 있기 때문에 WAS에서는 parent-first / child-last 방식의 클래스로딩 메커니즘이 아닌 parent-last / child-first 방식의 클래스로딩 메커니즘을 사용한다.

참고로 Tomcat에서는 아래와 같은 순서로 클래스로더를 사용한다. (엄밀히 말하면 parent-last / child-first가 아니라 Common과 웹앱만 순서가 바뀐 것이다.)

• Bootstrap
• System
• /WEB-INF/classes
• /WEB-INF/lib/*.jar
• Common

2014.08.12 추가

Tomcat이 아닌 다른 WAS들의 경우 모두 parent-last / child-first 방식을 디폴트로 따르는 것은 아닌 것 같다. 하지만 그런 WAS들의 경우 어떤 클래스로딩 메커니즘 방식을 사용할지 설정할 수 있다. 자체 서비스를 하는 기업의 경우 이런 설정을 자신들이 변경할 수 있지만 WAR 패키지로 판매하는 제품을 만드는 기업의 경우 WAS의 클래스로딩 메커니즘 설정에 따라 충돌이 발생할 수 있기 때문에 주의해야 한다.

http://epicdevs.com/16

1. serialize(직렬화) 란?  

 -> 메모리안의 어떠한 (추상적) 데이터구조를 연속된  bit  로  외부에 보내기위해 정렬하는것.

 2.  왜 직렬화를 해야하나? 

 -> 물리층 자체가  bit 니깐  /  가장 베이스적인 약속으로서 활용

 3. 위에서 외부란 ?

 -> 파일 / DB / 소켓을 통해 네트워크 외부등

4. 직렬화의 종류는 ?

 -> 데이터를 어떤식으로 구조화하냐에 따라서 달라짐. 예) 자바직렬화, 구글 프로토콜버퍼

 -> 프로토콜버퍼등은 데이터를 짧고 효율적이게 하는게 주목적.반면 자바직렬화는 낭비가 엄청남

5. 직렬화를 활용하는곳? 

-> 소켓통신, 자바객체를 파일에 저장 ( 파워포인트등의 내용을  파일(ppt) 로 저장할때도 객체직렬화)

6. 직렬화 예제  

다음은 int 형을 바이트배열로 직렬화하는 코드에요

C++ ) 

       inline static string intDATA(int  nData)
	{
		string value;
		value.clear();
		value.append("i");
		value.append((const char *)&nData, sizeof(nData));

		return value;
	}

        ...
        byte[] b = value.c_str();

nData 라는 int 형을 직렬화하는데, 일단 제일 앞에 1바이트로 "i" 문자열을 넣습니다.

그리고 int 형 데이터를 넣습니다. 나중에 저 string 에서  바이트배열로 뽑아내서 리모트로 보내면 

상대방은  1바이트를 읽어서  "i"  면  다음에 올 배열을  int 형으로 만들수있게 됩니다.  :-)

"d" 라면 다음에 올 바이트배열로 double 형을 만들어야할테지요.

Java )

ObjectOutputStream  out = new ObjectOutputStream(...);
out.writeInt(10);

 out 이라는 객체에 10이라는 int 형을 배열로 담고 있습니다.

 마찬가지로 double 형이라면 writeDouble 으로~

  writeInt 메소드의 내부에는 이렇게 되어있네요.

  public final synchronized void writeInt (int value) throws IOException
  {
      write ((byte) (0xff & (value >> 24)));
      write ((byte) (0xff & (value >> 16)));
      write ((byte) (0xff & (value >>  8)));
      write ((byte) (0xff & value));
  }

7. 직렬화 관련된 GOF 패턴 

현상태에 대한 스냅샷적인 저장  (메멘토패턴)

현 상태를 원격지로의 송신         (프록시패턴  // 프록시패턴하고 직접적인 관련은 없음)

4. 스프링 설정  :   어노테이션  vs   XML

MyBean.java 가  XML/어노테이션/자바 컨피그레이션을 통해   어떻게 객체로 만들어지는지 살펴보도록하자.

MyBean myBean = new MyBean(); 
myBean.setName("xmlBean");

AnotherBean anotherBean = new AnotherBean();
anotherBean.setMyBean(mybean);

AnotherBean [myBean=MyBean [name=xmlBean]]

AnotherBean [myBean=MyBean [name=AnnotationBean]]

AnotherBean [myBean=MyBean [name=JavaConfigBean]]

AnnotationConfigApplicationContext 분석 

위의 코드는 @Configuration 으로 <beans> 를 대신하고 
@bean 으로 자바코드에 의한 빈등록을 하게 해주는 예이다.

 AnnotationConfigApplicationContext  을 이용하여 설정 클래스를 입력받은후에 
 getBean 메소드를 통하여 내부의 특정 객체를 가져오는 소스이다.

AnnotationConfigApplicationContext  인사이드를 보도록 하자.

(분석중..) 

Reference 

3. 자바 리플렉션으로 어노테이션 다루기 

Class aClass = TheClass.class;
Annotation[] annotations = aClass.getAnnotations();

for(Annotation annotation : annotations){
    if(annotation instanceof MyAnnotation){
        MyAnnotation myAnnotation = (MyAnnotation) annotation;
        System.out.println("name: " + myAnnotation.name());
        System.out.println("value: " + myAnnotation.value());
    }
}

Class aClass = TheClass.class;
Annotation annotation = aClass.getAnnotation(MyAnnotation.class);

if(annotation instanceof MyAnnotation){
    MyAnnotation myAnnotation = (MyAnnotation) annotation;
    System.out.println("name: " + myAnnotation.name());
    System.out.println("value: " + myAnnotation.value());
}

public class TheClass {
  @MyAnnotation(name="someName",  value = "Hello World")
  public void doSomething(){}
}

Method method = ... //obtain method object
Annotation[] annotations = method.getDeclaredAnnotations();

for(Annotation annotation : annotations){
    if(annotation instanceof MyAnnotation){
        MyAnnotation myAnnotation = (MyAnnotation) annotation;
        System.out.println("name: " + myAnnotation.name());
        System.out.println("value: " + myAnnotation.value());
    }
}

Method method = ... // obtain method object
Annotation annotation = method.getAnnotation(MyAnnotation.class);

if(annotation instanceof MyAnnotation){
    MyAnnotation myAnnotation = (MyAnnotation) annotation;
    System.out.println("name: " + myAnnotation.name());
    System.out.println("value: " + myAnnotation.value());
}

public class TheClass {
  public static void doSomethingElse(
        @MyAnnotation(name="aName", value="aValue") String parameter){
  }
}

Method method = ... //obtain method object
Annotation[][] parameterAnnotations = method.getParameterAnnotations();
Class[] parameterTypes = method.getParameterTypes();

int i=0;
for(Annotation[] annotations : parameterAnnotations){
  Class parameterType = parameterTypes[i++];

  for(Annotation annotation : annotations){
    if(annotation instanceof MyAnnotation){
        MyAnnotation myAnnotation = (MyAnnotation) annotation;
        System.out.println("param: " + parameterType.getName());
        System.out.println("name : " + myAnnotation.name());
        System.out.println("value: " + myAnnotation.value());
    }
  }
}

public class TheClass {

  @MyAnnotation(name="someName",  value = "Hello World")
  public String myField = null;
}

Field field = ... //obtain field object
Annotation[] annotations = field.getDeclaredAnnotations();

for(Annotation annotation : annotations){
    if(annotation instanceof MyAnnotation){
        MyAnnotation myAnnotation = (MyAnnotation) annotation;
        System.out.println("name: " + myAnnotation.name());
        System.out.println("value: " + myAnnotation.value());
    }
}

Field field = ... // obtain method object
Annotation annotation = field.getAnnotation(MyAnnotation.class);

if(annotation instanceof MyAnnotation){
    MyAnnotation myAnnotation = (MyAnnotation) annotation;
    System.out.println("name: " + myAnnotation.name());
    System.out.println("value: " + myAnnotation.value());
}

Annotation & Reflection 예제 

* 메타 annotation type

1.@documented : 이 어노테이션을 자바독이나 유사한 도구로 문서화되어져야하는데 사용

하는 엘리먼트를 지칭

2.@Target : 어노테이션 타입이 수용할 수 있는 많은 프로그램 엘리먼트를 지칭

3.@Inherited : 자동으로 상속받는 어노테이션 타입을 지칭

4.@Retention : 어노테이션된 타입이 얼마나 지속되는가를 지칭


[메소드에 지정할 어노테이션 정보들을 정의해놓은 인터페이스] 

[어노테이션을 적용한 메소드들이 정의되어 있는 클래스 예] 

[Reflection을 사용하여 어노테이션 정보를 분석하는 클래스 :

테스트 클래스로 클래스의 모든 메소드를 로드하고, 그 메소드 중에 어노테이션 인터페이스

에 정의된 어노테이션을 마킹한 각 메소드에 한해서만 이하 작업을 수행.]

1.해당 메소드의 모든 어노테이션을 출력.

2.해당 메소드의 어노테이션 정보를 새 어노테이션 인터페이스 변수에 담고

그 변수에서 어노테이션 값이 사용자가 지정한 값을 가지고 있다면 해당메소드 출력.

Reference 

2. 자바 어노테이션 이야기

2-1. 왜 어노테이션인가?

자바 스펙에서 어노테이션은 다음에서 나타내 지고 있다 :

• JSR 175 A metadata facility for the Java programming Language
• JSR 250 Common Annotations for the Java Platform

2-2. 소개 

2-3. Consumers (소비자) 

어노테이션의 목적이 정확히 먼지, 어떻게 사용되는지 이해하는건 쉽지 않다, 그것들은 어떠한 기능적 로직을 가지고 있지 않으며 , 코드에 영향을 미치지 않는다.  어노테이션이 뭘 할까? 

이것을 위한 설명으로 난 어노테이션 컨슈머스라고 말하는게 있는데 ,  이것들은 시스템이나 서드파티 어플리케이션 (스프링같은) 으로서  어노테이션이 적용된  코드를 어노테이션 정보로부터 의존적인 여러가지 행동을 취한다.

예를들어 자바 빌트인 어노테이션경우에는 소비자는 자바가상머신(JVM) 이며 어노테이션이 적용된 코드를 실행한다.  사용자 정의 어노테이션의 경우의  예로는  JUnit, Spring 등이 있다.

그리고 소비자는 코드에서부터 어노테이션을 분석하기위해  자바 리플렉션을 이용한다. 

2-4. 유즈 케이스 

어노테이션은 다양한 목적으로 사용되는데 대표적으로는 

•  컴파일러를 위한 정보제공 :  Java 8 @FunctionalInterface , @supresswarnings
•  자동 문서 작성 :  generate reports automatically like Jenkins, Jira or Teamcity.
•  코드 자동 생성 :  A good example of this is the JAXB library.
•  런타임 프로세싱 : testing (Junit), dependency injection (Spring), logging (Log4J) ,data access (Hibernate) etc.

2-5. Java 8 에서 어노테이션 

Java 8 은 여러가지 훌륭한 기능을 가지고 왔는데 어노테이션 프레임워크도 발전되었다. 

다음 예예를 통해 확인해 보도록 하자.  

@Repeatable:  

Afterwards, we create the annotation itself and we mark it with the Meta annotation @Repeatable:

Finally we can see how to use it (repeatedly) in a given class:

If we would try to do the same with a non repeatable annotation:

We would get an error from the compiler like:

• Since Java 8 is also possible to use annotations within types. That is anywhere you can use a type, including the new operator, castings, implements and throws clauses. Type Annotations allow improved analysis of Java code and can ensure even stronger type checking. The following examples clarify this point:

All this was not possible until Java 8.

• @FunctionalInterface: this annotation indicates that the element annotated is going to be a functional interface. A functional interface is an interface that has just one abstract method (not a default one). The compiler will handle the annotated element as a functional interface and will produce an error if the element does not comply with the needed requirements. Here is an example of functional interface annotation:

This annotation can be applied to classes, interfaces, enums and annotations and it is retained by the JVM and available in Run time. Here is its declaration:

2-6. Retrieving   어노테이션 

자바 리플렉션 API 는 여러가지 메소드를 포함한다. 그 메소드들은 런타임에 클래스,메소드등으로부터  

어노테이션 정보를 얻을수있게 한다. 그것을 통해서 스프링같은 서드파티 프레임워크는 클래스들을 

조작할수있게 된다.

저런 모든 메소드들을 포함한 인터페이스는 AnnotatedElement 이며 대표적으로 다음과 같다.

• getAnnotations():  주어진 엘리먼트가 가지고있는 모든 어노테이션을 배열로 가져온다.
• isAnnotationPresent(annotation):  엘리먼트가 어노테이션을 가지고있는지 체크한다.
• getAnnotation(class): 파라미터로 넘겨진 엘리먼트에 대한 단일 어노테이션을 가져온다.

This class is implementing by java.lang.Class, java.lang.reflect.Method and java.lang.reflect.Field among others, so can be used basically with any kind of Java element.

Now we are going to see an example of how to read the annotations present in a class or method using the methods listed above:

We write a program that tries to read all the annotations present in a class and its methods (we use for this example the classes defined before):

The output of this program would be:

In the program above we can see the usage of the method getAnnotations() in order to retrieve all annotations for a given object (a method or a class). We also showed how to check if an specific annotation is present and to retrieve it in positive case using the methods isAnnotationPresent() and getAnnotation().

Reference 

선선한 토요일 아침에 뭐 할까 하다가 , 자바 어노테이션에 대해서 간략하게 정리해 놓아야겠다고 생각하고 

참고 싸이트들을 검색해보니, 오래된 기술이다 보니 역시나 좋은 글들이 많아서 .그것들을 번역/정리해 

보다보니 생각한것보다 엄청 길어져버렸다. ㅜㅜ

순서

1. 자바 어노테이션 기본 문법

Annotation 이름 

기본적으로 요렇게 생김

@Entity

@ <-- 요놈은 기본적으로 컴파일러에게 이게 어노테이션이다라고 알린다. 

@ 마크 다음에 오는 문자는  해당 어노테이션의 이름이고 여기서는  "Entity" !!!

Annotation 요소 (Element)

@Entity(tableName = "vehicles")

위에서는 tableName 이라는 이름의 요소를 하나 가지고있다는뜻이야. 값은 "vehicles" 이군. 

물론 아래와 같이 여러개의 요소를 가질수도있어.

@Entity(tableName = "vehicles", primaryKey = "id")

하나만 요소로 가질 경우 다음과 같이 짧게 줄여 쓸수도있지.

@InsertNew("yes")

Annotation 선언위치(Placement)

어노테이션은 클래스, 인터페이스, 메소드, 메소드 파라미터, 필드, 지역변수 위에 위치할수있어.

아래는 클래스 위에 선언되어있는 것이고

@Entity
public class Vehicle {
}

위에 말했다시피 @로 시작하고 이름은 Entity 야.  Entity 어노테이션은 그냥 내가 만든 어노테이션이고 현재 별 의미 없어. :-) 

아래 예는  모든 선언 위치에 어노테이션(주석)을 넣어봤어 함 봐바~  

(뭐 큰 역할을 하는건 아니지만 우리가 항상 사용하는 //  요런  주석으로써의 의미는 있다고 볼수있지  ) 

@Entity
public class Vehicle {

    @Persistent
    protected String vehicleName = null;


    @Getter
    public String getVehicleName() {
        return this.vehicleName;
    }

    public void setVehicleName(@Optional vehicleName) {
        this.vehicleName = vehicleName;
    }

    public List addVehicleNameToList(List names) {

        @Optional
        List localNames = names;

        if(localNames == null) {
            localNames = new ArrayList();
        }
        localNames.add(getVehicleName());

        return localNames;
    }

}

자바에서 기본적으로 제공되는 어노테이션 

• @Deprecated
• @Override
• @SuppressWarnings

@Deprecated

이 어노테이션은 , 해당 클래스/메소드 등은 더이상 지원하지 않으니 or  만들고 나니깐 별로 안좋은 

부분이 많거나, 더 좋은 해결법이 생겼으니 사용하지 마시라는 의미야. 그럼에도 불구하고 네가 그걸 

쓴다면 자바 컴파일러는 귀신같이 알아내서 경고 메세지를 날려줄것이지. 

(@Deprecated 주석때문에 컴파일러가 알아차릴수있는거라는 말) 

@Deprecated
public class MyComponent {

}

@Override

이 어노테이션은 슈퍼클래스에 대해 오버라이드 되었다는걸 알려줘. 따라서 만약 메서드가 

슈퍼클래스와 매칭되지 않았으면 에러를 날려주지. (컴파일러 만드는 사람들이 에러를 감지하기 

편하겠지?)  아래 예를 봅시다~

public class MySuperClass {

    public void doTheThing() {
        System.out.println("Do the thing");
    }
}


public class MySubClass extends MySuperClass{

    @Override
    public void doTheThing() {
        System.out.println("Do it differently");
    }
}

물론 이 어노테이션을 사용하는게 강제는 아니지만 , 사용하는게 좋을꺼야. 만약 슈퍼클래스가 

변경되었는데 그걸 모르고 자식클래스에서 오버라이딩한 클래스를 그대로 냅두면, 의도가 

깨져버리고 우리는 그 사실도 모른채 퇴근을 하겠지~  만약 @Override 를 선언해뒀다면 

바로 에러로 알려주고 네가 수정한후에 편한마음으로 컴백홈하게 도와줄꺼야

@SuppressWarnings 

이 어노테이션은 해당 메소드에 대해서 compiler suppress warnings (컴파일러 경고 억제?)을 

만들어. 예를들어 어떤 코드가 경고메세지를 수천개씩 쏟아내는데, 그게 보기싫을때 입막음 

시켜버리는거야 조용히~

@SuppressWarnings
public void methodWithWarning() {


}

개인용 어노테이션 만들기 

개인적으로 사용할 어노테이션을 만드는것이  가능하며 어노테이션은 클래스나 인터페이스처럼 

자신의 파일에 정의된다. 다음 예를 보자.

@interface MyAnnotation {

    String       value();
    String       name();
    int            age();
    String[]    newNames();

}

위의 어노테이션은 4개의 요소를 가지고있고 이름은 MyAnnotation  이다.

@interface 키워드를 주목하라  이것은 자바컴파일러에게 이놈이 어노테이션 정의라는걸 알려준다.

요소들은 인터페이스에서의 메서드 정의와 유사하다.  자바 기본요소들을 모두 사용할수있고 , 배열도 사용가능하다. (복잡객체사용은 불가능) 

 위에서 정의한 어노테이션을 사용해 보자.

@MyAnnotation(
    value="123",
    name="Jakob",
    age=37,
    newNames={"Jenkov", "Peterson"}
)
public class MyClass {


}

위에 보다시피 각각의 요소에 나만의 값을 지정했다. 후에 프레임워크에서  이 값을 파싱해서 필요한 정보를 알아낼것이다. 물론 님 스스로  리플렉션을 통해 저 어노테이션을 분석해서 사용할수도 있을테고~

* 저런 주석을 달아놓으면 나중에 클래스별로 그루핑을 할때 사용하거나 어떤 클래스/함수는 어떤것(URL 따위들) 과 매핑 같은것에 사용할수 있을거라는 생각을 잠시 해보자. 함수이름이 달라져도 어노테이션만 같으면 자동 매핑해줄수있지 않겠는가 

요소(Element)디폴트 값

요소에 기본값을 설정할수 있다. 아래 예를 보자.

@interface MyAnnotation {

    String   value() default "";

    String   name();
    int      age();
    String[] newNames();

}

디폴트값을 설정해두면 아래와 같이 사용할때 값을 넣지 않아도 된다. (아예 보이지도 않음) 

@MyAnnotation(
    name="Jakob",
    age=37,
    newNames={"Jenkov", "Peterson"}
)
public class MyClass {


}

@Retention    -  네이버 사전 :  (어떤 것을 잃지 않는) 보유[유지])

얼마나 오랫동안 어노테이션 정보가 유지되는지 설정할수있다. 

아래 예를 보자. 

import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;

@Retention(RetentionPolicy.RUNTIME)

@interface MyAnnotation {

    String   value() default "";

}

@Target 

자신이 만든 어노테이션이 사용되게될 자바 요소를 지정할수있다. 아래 예를 보자.

import java.lang.annotation.ElementType;
import java.lang.annotation.Target;

@Target({ElementType.METHOD})
public @interface MyAnnotation {

    String   value();
}

위처럼 만들면 메소드에서만 사용가능한 어노테이션을 정의할수있다.아래와 같이 타겟을 정할수있다.

• ElementType.ANNOTATION_TYPE
• ElementType.CONSTRUCTOR
• ElementType.FIELD
• ElementType.LOCAL_VARIABLE
• ElementType.METHOD
• ElementType.PACKAGE
• ElementType.PARAMETER
• ElementType.TYPE

@Inherited

The @Inherited 어노테이션은 이 어노테이션을 사용한 슈퍼클래스를 상속한 서브클래스에서도
해당 어노테이션을 갖도록 한다.

java.lang.annotation.Inherited

@Inherited
public @interface MyAnnotation {

}

@MyAnnotation
public class MySuperClass { ... }

public class MySubClass extends MySuperClass { ... }

MySubClass 클래스는 @MyAnnotation 을 상속한다. 

@Documented

@Documented 어노테이션이 지정된 대상의 JavaDoc 에 이 어노테이션의 존재를 표기하도록 지정.

java.lang.annotation.Documented

@Documented
public @interface MyAnnotation {

}

@MyAnnotation
public class MySuperClass { ... }

Reference 

자바에서 예외(Exception)은 크게 checked 예외와 unchecked 예외로 나뉘어진다. checked 예외는 코드에서 명시적으로 try-catch-finally 예외 처리를 해야하는 것을 의미하며, unchecked 예외는 그럴 필요가 없는 것을 의미한다. checked 예외에서 try-catch로 예외를 처리하지 않는 경우에는 메소드에 throws 절을 추가해야 한다.

자바에서 checked 예외는 java.lang.Exception 을 상속받는 형태이며, unchecked 예외는 java.lang.RuntimeException을 상속받는 예외이다. checked 예외이든 unchecked 예외이든 두가지 모두 동일한 기능을 수행한다. 따라서, 어느 것이 더 낫다라고 말할 수는 없다. 하지만, 예외 발생시 어떠한 로직을 추가하느냐에 따라서 그 비용적인 측면은 다양할 수 있다.

 또한, 트랜잭션, 원격 호출과 같은 지점에서 주로 런타임 계열의 unchecked 예외를 사용하는 것이 일반적이며, 이는 기반 기술 (J2EE, Spring)들이 런타임 계열의 예외에 대해 자동으로 트랜잭션 처리를 해주고 있다. (Spring에서는 checked 예외에 대해서는 트랜잭션 처리가 가능하지만, 관행과 같이 런타임 계열을 사용하는 방식을 권고한다.)

(눈여겨 볼것은 바로 예외발생시 트랜잭션의 roll-back 여부이다. 기본적으로 Checked Exception은 예외가 발생하면 트랜잭션을 roll-back하지 않고 예외를 던져준다. 하지만 Unchecked Exception은 예외 발생 시 트랜잭션을 roll-back한다는 점에서 차이가 있다. 트랜잭션의 전파방식 즉, 어떻게 묶어놓느냐에 따라서 Checked Exception이냐 Unchecked Exception이냐의 영향도가 크다. roll-back이 되는 범위가 달라지기 때문에 개발자가 이를 인지하지 못하면, 실행결과가 맞지 않거나 예상치 못한 예외가 발생할 수 있다. 그러므로 이를 인지하고 트랜잭션을 적용시킬 때 전파방식(propagation behavior)과 롤백규칙 등을 적절히 사용하면 더욱 효율적인 애플리케이션을 구현할 수 있을 것이다.)

비즈니스 예외의 경우, 내부적으로 특정 예외를 지정하여 사용할 때에는 checked 예외를 사용하기도 하지만, 런타임 계열의 예외를 사용하는 것이 추가 코드가 들어가지 않고, try-catch로 별도 로직을 구성하지 않는 이상 checked 예외를 사용하는 것은 여러가지로 고려해서 신중할 필요가 있다. 보통 예외를 먹는다는 표현과 같이 try-catch 구문 안에서 checked 예외를 처리하고 catch 절에서 아무런 행위를 하지 않으면, 예외 발싱시 문제점을 추적하기가 쉽지 않다.

위의 코드가 대표적으로 예외를 먹는 행위이다. 물론, 예외 처리를 하지 않는 명확한 이유가 있고, 그 안에서 대부분의 예외를 처리한다고 하면, 이와 같은 코드는 크게 상관은 없을 수도 있겠지만, 일반적으로 보아서, 예외를 catch하고 이를 호출하는 측에 아무런 반응을 알리지 않는다면 좋지 않은 코드가 될 가능성이 높다.

또한, 예외를 예외로 받지 않고, 예외 발생시 다양한 코드를 받게끔 처리하는 경우도 있는데, 이러한 경우 예외에 대한 모든 경우들을 검토해야 한다. (마치 HTTP로 통신시 예외에 대한 코드를 정의하듯이 예외코드와 정확한 의미를 상세하게 정의해야 한다.)

이러한 다양한 경우들을 처리하는 것에 대한 부담이 있고, 어떻게 처리할지를 잘 모르겠다면 시스템 내부에서의 예외는 가능하다면 모두 Runtime 계열로 처리하고, UI 접점에서 이러한 예외들을 처리하게끔 하는 것이 가장 나은 방법인 것 같다. UI에서 이러한 다양한 예외들을 어떻게 보여줄 것인지에 대한 고민은 사용자의 요구사항을 들을 필요가 있지만, 대부분이 그냥 시스템에 문제가 있다라는 형태의 오류만을 보기를 원할 것이다. 사실 예외 메시지에 대한 대부분은 개발자들이 보고 싶은 데이터이지 사용자에게 의미있는 정보들은 아니다. (물론, 입력 폼 처리에서 어떠한 정보가 누락되었는지 정합성이 문제가 되었는지는 가능하면 상세하게 보여줄 필요가 있지만, DB 오류 코드나, SQL 구문, 내부 시스템 네트워크 문제, 잘못된 코드 등을 사용자에게까지 보여줄 필요는 없을 것이다.)

결국, 예외는 개발/운영하는 사람들을 위해서 수집하도록 하면 되고, 문제 발생시 추적하여 해결할 수 있는 수준에서 예외 처리를 하면 된다. 즉, UI 접점 내의 서버에는 모든 예외가 런타임 계열로 정의하고(물론, 필요한 경우 checked 예외를 선언하여 처리하면 된다. 다만 이 경우는 세심한 주의가 필요할 뿐이다.), UI에서 발생되는 예외를 비동기로 분석하여 추후 문제 해결시 사용하면 된다. 예외는 전체 시스템 차원에서 처리하는 방식과 일정한 형식을 필요로 하며, 문제를 해결할 수 있는 수준에서 적당하게 사용하면 된다. 또한, 예외코드 사용시 상세한 내용을 문서화/명세화시켜서 남겨두어야 한다. 

예외를 처리하는 3가지 방법

1. 예외 복구

[리스트 1] 재시도를 통해 예외를 복구하는 코드

예외복구의 핵심은 예외가 발생하여도 애플리케이션은 정상적인 흐름으로 진행된다는 것이다. 위 [리스트 1]은 재시도를 통해 예외를 복구하는 코드이다. 이 예제는 네트워크가 환경이 좋지 않아서 서버에 접속이 안되는 상황의 시스템에 적용하면 효율 적이다. 예외가 발생하면 그 예외를 잡아서 일정 시간만큼 대기하고 다시 재시도를 반복한다. 그리고 최대 재시도 횟수를 넘기면 예외를 발생시킨다.  재시도를 통해 정상적인 흐름을 타게 한다거나, 예외가 발생하면 이를 미리 예측하여 다른 흐름으로 유도시키도록 구현하면 비록 예외가 발생하였어도 정상적으로 작업을 종료할 수 있을 것이다.

2. 예외처리 회피

[리스트 2] 예외처리 회피

위 [리스트 2]는 간단해 보이지만 아주 신중해야하는 로직이다. 예외가 발생하면 throws를 통해 호출한쪽으로 예외를 던지고 그 처리를 회피하는 것이다. 하지만 무책임하게 던지는 것은 위험하다. 호출한 쪽에서 다시 예외를 받아 처리하도록 하거나, 해당 메소드에서 이 예외를 던지는 것이 최선의 방법이라는 확신이 있을 때만 사용해야 한다.

3. 예외 전환

[리스트 3] 예외전환 

예외 전환은 위 [리스트 3]에서 처럼 예외를 잡아서 다른 예외를 던지는 것이다. 호출한 쪽에서 예외를 받아서 처리할 때 좀 더 명확하게 인지할 수 있도록 돕기 위한 방법이다. 어떤 예외인지 분명해야 처리가 수월해지기 때문이다. 예를 들어 Checked Exception 중 복구가 불가능한 예외가 잡혔다면 이를 Unchecked Exception으로 전환하여서 다른 계층에서 일일이 예외를 선언할 필요가 없도록 할 수도 있다.

이상으로 예외를 처리하는 3가지 방법을 알아봤다. 하지만 예외를 처리하는 방법보다도 초급 개발자가 가장 잊지 말아야 할 것은 예외를 잡고 아무런 처리도 하지 않는 것은 정말 위험한 행위라는 것이다. try/catch문으로 예외를 잡아놓고 catch를 비워두면 물론 컴파일 오류는 나지 않겠지만, 예외가 발생했을 때 그 원인을 파악하기가 어려워 개발은 물론 유지보수에 아주 치명적인 민폐를 끼치는 일이라고 생각한다. 따라서 어떤 처리를 해야 하는지 모르더라도 무작정 catch하고 무시하거나, throw해버리는 행위를 할 때는 더욱 신중해야 할 것이다.

트랜잭션 (Transaction)

갑자기 "트랜잭션"이라는것이 나와서 뜬금없다고 생각할 수도 있겠지만 트랜잭션과 예외처리는 매우 밀접한 관련이 있다. 트랜잭션과 예외처리가 서로 어떤 관련이 있는지 알아보도록 하자.

트랜잭션은 하나의 작업 단위를 뜻한다.

쇼핑몰의 "상품발송"이라는 트랜잭션을 가정 해 보자.

"상품발송"이라는 트랜잭션에는 다음과 같은 작업들이 있을 수 있다.

• 포장
• 영수증발행
• 발송

이 3가지 일들 중 하나라도 실패하면 3가지 모두 취소하고 "상품발송"전 상태로 되돌리고 싶을 것이다. (모두 취소하지 않으면 데이터의 정합성이 크게 흔들리게 된다. 이렇게 모두 취소하는 행위를 보통 전문용어로 롤백(Rollback)이라고 말한다.)

프로그램이 다음과 같이 작성되어 있다고 가정 해 보자. (※ 아래는 실제 코드가 아니라 어떻게 동작하는지를 간략하게 표현한 pseudo 코드1이다.)

상품발송() {
    포장();
    영수증발행();
    발송();
}

포장() {
   ...
}

영수증발행() {
   ...
}

발송() {
   ...
}

쇼핑몰 운영자는 포장, 영수증발행, 발송이라는 세가지 중 1가지라도 실패하면 모두 취소하고 싶어한다. 이런경우 어떻게 예외처리를 하는 것이 좋겠는가? ^^

다음과 같이 포장, 영수증발행, 발송 메서드에서는 예외를 throw하고 상품발송 메서드에서 throw된 예외를 처리하여 모두 취소하는 것이 완벽한 트랜잭션 처리 방법이다.

상품발송() {
    try {
        포장();
        영수증발행();
        발송();
    }catch(예외) {
       모두취소();
    }
}

포장() throws 예외 {
   ...
}

영수증발행() throws 예외 {
   ...
}

발송() throws 예외 {
   ...
}

위와 같이 코드를 작성하면 포장, 영수증발행, 발송이라는 세개의 단위작업 중 하나라도 실패할 경우 "예외"가 발생되어 상품발송이 모두 취소 될 것이다.

만약 위 처럼 "상품발송" 메서드가 아닌 포장, 영수증발행, 발송메소드에 각각 예외처리가 되어 있다고 가정 해 보자.

상품발송() {
    포장();
    영수증발행();
    발송();
}

포장(){
    try {
       ...
    }catch(예외) {
       포장취소();
    }
}

영수증발행() {
    try {
       ...
    }catch(예외) {
       영수증발행취소();
    }
}

발송() {
    try {
       ...
    }catch(예외) {
       발송취소();
    }
}

이렇게 각각의 메소드에 예외가 처리되어 있다면 포장은 되었는데 발송은 안되고 포장도 안되었는데 발송이 되고 이런 뒤죽박죽의 상황이 연출될 것이다.

실제 프로젝트에서도 두번째 경우처럼 트랜잭션관리를 잘못하여 고생하는 경우를 많이 보았는데 이것은 일종의 재앙에 가깝다.

이번 챕터에서는 자바의 예외처리에 대해서 알아보았다. 사실 예외처리는 자바에서 좀 난이도가 있는 부분에 속한다.

보통 프로그래머의 실력을 평가 할 때 이 예외처리를 어떻게 하고 있는지를 보면 그 사람의 실력을 어느정도 가늠해 볼 수 있다고들 말한다. 예외처리는 부분만 알아서는 안되고 전체를 관통하여 모두 알아야만 정확히 할 수 있기 때문이다.