4장 예외

4장에서는 애플리케이션에서 사용할 수 있는 바람직한 예외처리 방법에 대해 소개 되어 있다. 이 장에서는 많은 내용이 있지 않으므로 간략하게 정리만 하고 넘어가도록하겠다. 

■ 예외를 잡아서 아무런 조취를 취하지 않거나 의미 없는 throws 선언을 해서는 안된다.
■ 예외는 복구 하거나 예외처리 오브젝트로 의도적으로 전달하거나 적절한 예외로 전환해야 한다.
■ 좀 더 의미 있는 예외로 변경하거나, 불필요한 catch/throws를  피하기 위해 러니타임 예외로 포장하는 두 가      지 방법의 예외 전환이 있다.
■ 복구 할 수 없는 예외는 가능한 한 빨리 런타임 예외로 전환하는 것이 바람직하다.
■ 애플리케이션의 로직을 담기 위한 예외는 체크예외로 만들어라JDBC의 SQLException은 대부분 복구할 수 없      는 예외이므로 런타임 예외로 포장해야 한다.
■ SQLException의 에러코드는 DB에 종속되기 때문에 DB에 독립적인 예외로 전환된 필요가 있다.
■ 스프링은 DataAccessException을 통해 DB에 독립적으로 적용 가능한 추상화된 런타임 예외 계층을 제공한다. ■ DAO를 테이터 엑세스 기술에서 독립시키려면 인터페이스 도입과 런타임 예외 전환, 기술에 독립적인 추상화     된 예외로 전환이 필요하다. 

     아래 코드는 위 내용을 글로만 읽으니 ,이해가 어려워 코드에 직접 적용해봤다. 아래 코드를 보면 좀더 이해가 쉬울       듯하다. 주석으로 추가 설명을 해뒀으니 참고하자. 

	/*
	 * 4장 예외 공부하면서 적용해본 코드... 
	 * 무의미한 throws SQLException은 좋지 않다. 
	 * 차라리 unchecked Exception으로 포장 해서 던지는 것이 낫다. 
	 * 그리고 구체적으로 꼭 처리해야할  Exception인 경우는 예외 전환을 해주는 것이 좋다. 
	 * -> 이경우 메소드 옆에 throws을 꼭 해줘라. 그래야만 이 함수를 이용하는 다른 프로그래머가 구체적인 예외를 알수있다.
	 * -> 이런 에러도 RuntimeException을 상속 받도록 해서 임의로 unchecked Exception으로 만들어 둬라. 
	 *    그래야만 무의한 throws Exception 형식을 막을 수 있다. 
	 *    RuntimeException이라 하더라도 필요에 의해 try/catch throws를 사용하여 처리 할 수 있기 때문에 RuntimeException으로 처리 하는게 옳다. 
	 * */
	public void add(final User user) throws DuplicateUserIdException {	
		try {
			this.jdbcContext.workWithStatementStrategy(
				 new StatementStrategy() {
					 public PreparedStatement makeStatement(Connection c) throws SQLException {
							PreparedStatement ps = c.prepareStatement(
									"insert into users(id, name, password) values(?,?,?)");
								ps.setString(1, user.getId());
								ps.setString(2, user.getName());
								ps.setString(3, user.getPassword());
							return ps;
						}
				 }				
			);
		}catch(SQLException e) {
			if(e.getErrorCode() == 1505) {
				throw new DuplicateUserIdException(e);
			}else {
				throw new RuntimeException(e);
			}
		}
	}

•