[펌] Exceptional practices, Part 1

Exceptional practices, Part 1

Use exceptions effectively in your programs

 

original resource : http://www.javaworld.com/javaworld/jw-08-2001/jw-0803-exceptions.html

 

Exception은 Java Program에서 error를 handling하는 강력한 mechanism이다.
exception에 대한 고려를 많은 개발자들은 class를 design할 때 생각하는 것이 아니라 개발 process에서 결정하는
경향이 있다. 이는 적절치 않다.
exception에 대한 설계는 개발시점에 하는 것이 아니라 class design time에 하는 것이다.

아래의 간단한 exception class와 exception을 throw 하는 class를 보자.

 

package com.me.mypackage;

public class ResourceLoadException extends Exception {
  public ResourceLoadException(String message) {
    super(message);
  }
}

...

public class ResourceLoader {
  public getResource(String name) throws ResourceLoadException {
  ...
}

getResource() method가 ResourceNotFoundException를 throw할 때 아래의 세가지 중요한 정보를 가지게 된다.

 

1. The kind of exception that occurred (in this case, a ResourceNotFoundException)
2. The location where the exception occurred, in the form of a stack trace contained within the exception
3. Additional information about the exception, in the form of the message string

 

exception type은 getResource() method의 caller 에게 중요하며 stack trace는 developer나 technician에게 중요하고 message string은 user에게 중요하다.

 

Write sensible throws clauses

 

getResource() method는 database로부터 resource를 load 할수도 있고 file로부터 load할 수도 있고 또는 remote server로부터 load할 수도 있다.
이런 경우 getResource() method는 IOException, SQLException, RemoteException을 throw 할 것이고 caller들은 이런 exception들을 각각 처리해 주어야 한다
이것이 의미가 있을까?
중요한 것은 getResource method에서는 resource를 load하지 못했다는 것이다.
따라서 이럴경우에는 하나의 ResourceLoadException 을 throw 하는 것이 낫다.

 

There is no hard-and-fast rule about how many exception types a method should throw, but fewer is generally better.

 

하나의 method가 throw 하는 exception type의 갯수에 대한 엄격한 rule은 없지만 되도록이면 최소화하는 것이 좋다.
왜냐면 method가 throw하는 exception들을 caller들은 다시 throw 하거나 catch해서 처리를 해야되고 이것은 점점 method를 사용하는 것을 어렵게 만들기 때문이다.

 

If you throw too many exception types, callers might get lazy and simply catch Exception -- or, worse, throw Exception.

아주 많은 exception type을 throw하기 때문에 caller에서는 catch Exception 하거나 throw Exception 하는 경우도 있는데 이것은 개별적인 excetion type을 handling할 수 없기 때문에 적절치 않다.

 

Make your throws clauses stable

There is another significant advantage to throwing a small number of higher-level exception types instead of many individual low-level exception types:
it prevents the throws clause from changing every time the method changes.

 

많은 low-level exception type을 throw 하는 것보다 higher-level로 throw 하는 것의 장점이 하나 더 있다. 그것은 method가 변경될 때마다 throws clause의 변경을 미연에 방지할 수 있다.
method의 signature가 변경되면 그에 맞추어 caller 쪽에서도 동시에 변경이 일어나야 한다.
이는 얼마나 많은 caller가 있는지 얼마나 많은 개발자들이 이 method를 call 하는지에 따라서 엄청나게 많은 문제를 야기할 수 있다.

따라서 throw clause는 stable하게 작성할 필요가 있다.

What to do with exceptions you don't want to throw

public class ResourceLoader {
  public getResource(String name) throws ResourceLoadException {
  try {
    // try to load the resource from the database
    ...
  }
  catch (SQLException e) {
    throw new ResourceLoadException(e.toString()):
  }
}

 

위에처럼 작성하면 program과 이 method를 사용하는 user 둘 다 필요한 정보를 얻을 수 있다.
caller는 SQLException이나 IOExcepton이 아닌 좀 더 의미있는 error type을 얻을 수 있다.

 

Don't forget the user

error message는 개발자에게는 error의 source와 이유를 설명하고 user에게는 어떤 이유로 error가 발생했는지를 설명하는데 중요한다.
user에게 error message를 이해시키기 위해서는 resource  bundle을 이용하여 localized한 error message를 작성할 필요가 있다.
class에 error message 를 fixing하는 것은 바람직하지 않다.

 

Use exceptions properly

 

Proper exception handling is critically important.

하지만 application이나 class design시 충분히 고려하지 않거나 종종 무시하는 경우가 많다.

 

Good exception handling practices don't just make your programs more robust and easier to maintain;
when something bad happens, the thrown exception might provide the only clue as to what went wrong.

excepton 처리를 훌륭하게 하는 것이 program의 robustness와 유지보수성을 좋게 하는 것은 아니지만 어디서 잘못이 일어났는지를 알려주는 유일한 단서가 된다.