inner side

Most of the time, client code cannot do anything about SQLExceptions. Do not hesitate to convert them into unchecked exceptions. Consider the following piece of code:

public void dataAccessCode()

{    

try{        ..some code that throws SQLException    }

catch(SQLException ex)

{        ex.printStacktrace();    }}

This catch block just suppresses the exception and does nothing. The justification is that there is nothing my client could do about an SQLException. How about dealing with it in the following manner?

public void dataAccessCode()

{    

try{        ..some code that throws SQLException    }

catch(SQLException ex){        

throw new RuntimeException(ex);    }}<--그젠가 상위클래스던,인터페이스던.. abstract으로 사용자가 재정의

해야할 Thread의 run() 같은 메서드에서 예외를 throw해야할 상황이 있을때 선생님께서 런타입으로 캐스팅

해서 넘기면 된다고 말씀하심.

This converts SQLException to RuntimeException. If SQLException occurs, the catch clause throws a newRuntimeException. The execution thread is suspended and the exception gets reported. However, I am not corrupting my business object layer with unnecessary exception handling, especially since it cannot do anything about an SQLException. If my catch needs the root exception cause, I can make use of thegetCause() method available in all exception classes as of JDK1.4.

If you are confident that the business layer can take some recovery action when SQLException occurs, you can convert it into a more meaningful checked exception. But I have found that just throwingRuntimeException suffices most of the time.

What is wrong with following code?

public class DuplicateUsernameException    extends Exception {}

It is not giving any useful information to the client code, other than an indicative exception name. Do not forget that Java Exception classes are like other classes, wherein you can add methods that you think the client code will invoke to get more information.

We could add useful methods to DuplicateUsernameException, such as:

public class DuplicateUsernameException    extends Exception  <-마찬가지로 배운것~(주문에 대한

재고수량 정보 리턴)

{    public DuplicateUsernameException         (String username){....} 

   public String requestedUsername(){...}    

public String[] availableNames(){...}}

The new version provides two useful methods: requestedUsername(), which returns the requested name, and availableNames(), which returns an array of available usernames similar to the one requested. The client could use these methods to inform that the requested username is not available and that other usernames are available. But if you are not going to add extra information, then just throw a standard exception:

throw new Exception("Username already taken");

Best Practices for Using Exceptions

The next set of best practices show how the client code should deal with an API that throws checked exceptions.

1. Always clean up after yourself <- 내가예전에 고민했던 결론 (자기의 업무 영역에 따른 책임분할)

If you are using resources like database connections or network connections, make sure you clean them up. If the API you are invoking uses only unchecked exceptions, you should still clean up resources after use, with try - finally blocks.

public void dataAccessCode(){

    Connection conn = null; 

   try{        conn = getConnection();    

    ..some code that throws SQLException    

}catch(SQLException ex)

{        ex.printStacktrace();    }

 finally{        DBUtil.closeConnection(conn);    }}

class DBUtil{    public static void closeConnection        

(Connection conn){        try{            conn.close();        } 

catch(SQLException ex){            

logger.error("Cannot close connection");          

  throw new RuntimeException(ex);        }   

 }}

DBUtil is a utility class that closes the Connection. The important point is the use of finally block, which executes whether or not an exception is caught. In this example, the finally closes the connection and throws a RuntimeException if there is problem with closing the connection.

2. Never use exceptions for flow control <- 내가 요 유혹에 빠지기도 했었음..

Generating stack traces is expensive and the value of a stack trace is in debugging. In a flow-control situation, the stack trace would be ignored, since the client just wants to know how to proceed.

In the code below, a custom exception, MaximumCountReachedException, is used to control the flow.

public void useExceptionsForFlowControl() 

{    

try {        while (true) 

{            increaseCount();        }   

 } catch (MaximumCountReachedException ex) 

{    }    //Continue execution

}

public void increaseCount()    throws MaximumCountReachedException 

{    if (count >= 5000)        throw new MaximumCountReachedException();

}

The useExceptionsForFlowControl() uses an infinite loop to increase the count until the exception is thrown. This not only makes the code difficult to read, but also makes it slower. Use exception handling only in exceptional situations.

3. Do not suppress or ignore exceptions <-몇일 전 까지 core api익셉션을 무조건 누르려고 했었음(현재는 발생

When a method from an API throws a checked exception, it is trying to tell you that you should take some counter action. If the checked exception does not make sense to you, do not hesitate to convert it into an unchecked exception and throw it again, but do not ignore it by catching it with {} and then continue as if nothing had happened.

4. Do not catch top-level exceptions <-- 노력해볼꼐요 -_-;  구현 과정중에 이것저것 신경쓸께 너무 많아져서

Unchecked exceptions inherit from the RuntimeException class, which in turn inherits from Exception. By catching the Exception class, you are also catching RuntimeException as in the following code:

try{..}catch(Exception ex){}

The code above ignores unchecked exceptions, as well.

5. Log exceptions just once

Logging the same exception stack trace more than once can confuse the programmer examining the stack trace about the original source of exception. So just log it once.