>> Change Log: http://static.springsource.org/spring/docs/3.0.0.RC1/changelog.txt

그리고, 아래는 이번에 RC1에 추가된 내용이다.

Changes in version 3.0.0.RC1 (2009-09-25)
-----------------------------------------

* upgraded to CGLIB 2.2, AspectJ 1.6.5, Groovy 1.6.3, EHCache 1.6.2, JUnit 4.7, TestNG 5.10
* introduced early support for JSR-330 "javax.inject" annotations (for autowiring)
* introduced early support for JSR-303 Bean Validation (setup and MVC integration)
* added default editors for "java.util.Currency" and "java.util.TimeZone"
* refined PathMatchingResourcePatternResolver's treatment of non-readable directories
* PathMatchingResourcePatternResolver understands VFS resources (i.e. works on JBoss 5.x)
* revised AccessControlContext access from BeanFactory
* AbstractBeanDefinitionParser can deal with null return value as well
* PropertyOverrideConfigurer's "ignoreInvalidKeys" ignores invalid property names as well
* PropertyPlaceholderConfigurer supports "${myKey:myDefaultValue}" defaulting syntax
* BeanFactory's default type conversion falls back to String constructor on target type
* BeanFactory tries to create unknown collection implementation types via default constructor
* BeanFactory supports ObjectFactory as a dependency type for @Autowired and @Value
* BeanFactory supports JSR-330 Provider interface as a dependency type for @Inject
* BeanFactory prefers local primary bean to primary bean in parent factory
* protected @Autowired method can be overridden with non-annotated method to suppress injection
* private @Autowired methods with same signature will be called individually across a hierarchy
* @PostConstruct processed top-down (base class first); @PreDestroy bottom-up (subclass first)
* ConfigurationClassPostProcessor detect @Bean methods on registered plain bean classes as well
* support for default "conversionService" bean in an ApplicationContext
* MBeanServerFactoryBean returns JDK 1.5 platform MBeanServer for agent id "" (empty String)
* changed NamedParameter/SimpleJdbcOperations parameter signatures to accept any Map value type
* refined logging in JMS SingleConnectionFactory and DefaultMessageListenerContainer
* introduced "ui.format" package as an alternative to PropertyEditors for data binding
* @RequestMapping annotation now supported for annotated interfaces (and JDK proxies) as well
* @RequestParam and co support placeholders and expressions in their defaultValue attributes
* @Value expressions supported as MVC handler method arguments as well (against request scope)
* JSR-303 support for validation of @MVC handler method arguments driven by @Valid annotations
* refined response handling for @ExceptionHandler methods
* @ResponseStatus usage in handler methods detected by RedirectView
* all @SessionAttributes get exposed to the model before handler method execution
* @Event/ResourceMapping uniquely mapped to through event/resource id, even across controllers
* MultipartRequest is available as a mixin interface on (Native)WebRequest as well
* removed outdated "cacheJspExpressions" feature from ExpressionEvaluationUtils
* introduced common ErrorHandler strategy, supported by message listener container
* Jpa/JdoTransactionManager passes resolved timeout into Jpa/JdoDialect's beginTransaction
* HibernateJpaDialect applies timeout onto native Hibernate Transaction before begin call
* Spring's Hibernate support is now compatible with Hibernate 3.5 beta 1 as well
* Spring's JPA support is now fully compatible with JPA 2.0 as in EclipseLink 2.0.0.M7
* SpringJUnit4ClassRunner is now compatible with JUnit 4.5, 4.6, and 4.7
* SpringJUnit4ClassRunner once again supports collective timeouts for repeated tests
* deprecated @NotTransactional annotation for test classes in favor of @BeforeTransaction

지난번 글에서는 자바에서 Exception Handling이 어떻게 생성되고, 호출하는 코드로 어떻게 알려주게 되는지를 간략하게 이야기 하였다. (뭐 간략하다고 했지만, 이미 알고 있는 내용들이 었을 것이다.)

그리고 RuntimeException의 유형의 예외들은 컴파일러에서 신경을 쓰지 않기 때문에, 반드시 Try-Catch로 블록을 만들어 줄 필요가 없다는 것을 이야기 했다. (이 경우는 개발자가 코드상에서 해결해 주어야 한다는 것도 같이 이야기 했다.)

마지막으로, Eclipse와 같은 IDE에서 자동으로 생성되는 예외 처리 코드에 관해서도 이야기 했는데, 자동으로 생성되는 메커니즘도 이야기 했었는데, 더불어서 사용할 때 주의해야 할 것은 자동으로 생성된 코드로 인해서 예외처리가 끝났다고 착각하지 말아야 한다는 것이다. 실제 예외에 대해서 프로그램 또는 클래스에서 예외처리에 대한 코드가 들어가야하고, 이를 로그로 저장하거나 화면에 뿌려줄때는 좀더 사용자 친화적인 내용으로 저장하고, 보여주어야 추후에 유지보수하기 쉽다.

오늘은 이전에 시간이 모자라서 하지 못했던 이야기를 하려고 한다.

일반적으로 try-catch블럭의 사용을 잘 알고 있을 것이고, 더불어서 finally의 사용 또한 잘 알고 있을 거라 생각한다. 호출해야 할 코드는 try블록에다 정의하고 만약 예외가 호풀되면, 이를 제어하기 위해서 catch 블록에서 정의한 코드가 호출되고, 그리고 다시 코드가 실행된다. (try 블록에서 예외가 발생했던 코드 라인 이후는 호출이 되지 않는다.)

만약, 여기에 finally구문을 사용할 경우가 있는데, 아시다 시피 이는 try 또는 catch블록에 정의된 내용이 실행과 상관없이 정의되어 있다면 만드시 실횅되도록 정의되어 있다.

이 경우에 try 또는 catch구문에 return 문이 있다면 어떻게 될까?

try 또는 catch 블록에 return 문이 있다면, 일단 finally구문에 정의된 소소 코드들을 실행하고 나서 다시 return문으로 돌아 온다는 점에 유의 해야 한다.

예외도 객체이기 때문에 이를 상속받아서 새로운 예외들을 만들수 있다. 때문에 예외처리시에 아래와 같이 모든 예외를 한번에 다 잡을 수도 있지만, 이는 바람직하지 않다. 이전글에서 설명한 것처럼 어떤 메소드를 호출할때 어떤 메소드가 호출될 것인지가 클래스와 메소드 정의서가 정의된 문서를 보면 확인할 수 있다.

위의 코드의 경우는 예외느 다 잡을수 있을지 모르지만, 어떤식으로 예외를 관리할지는 전혀 알수 없다. (물론 때에 따라서는 상위의 예외로 부터 하위의 것을 모두 잡는 것이 유용할 수도 있다. 따라서 유의해서 사용해야 한다.) 꼭 필요한 경우가 아니라면, 예외별로 잘 정의해서 사용해야 한다. 아래는 예이다.

마지막으로 정말 중요한 것은, 예외 처리에서 순서가 있다는 것이다.

그렇기 때문에 다중으로 예외를 선언한 경우에 주의가 필요하다. 만약 어떤 예외를 상속 받아서 새로운 Exception 들을 만들었다면, 상속 받았던 에외들을 먼저 선언해 주어야 한다. 그렇지 않다면, 원하지 안는 결과를 얻을 수도 있다.

왜냐하면, JVM 에서는 첫번째 Catch블록에서 부터 호출된 예외를 처리한 Catch블럭을 찾아 내려오기 때문이다. 만약 가능한 예외 블록이 있다면, 비교를 멈추고 catch블록에 정의된 예외처리 코드들을 실행하게 된다.

따라서 만약에 첫번째 catch블록이 catch(Exception ex)라고 정의되어 있다면, 컴파일러는 다른 catch블록이 전혀 필요 없다고 생각할 것이다. (왜냐하면 이외의 catch 블록의 코드는 전혀 실행되지 않을 것이기 때문이다.) 

아래 코드에서 어떤 코드는 실행되지 않을 까요? 

내가 하고 싶은 이야기는 사실 마지막에 이야기 하고 싶은 내용이었다. Exception에도 순서가 있고 진행되는 방향이 있다. 하지만 이를 모르고서 코드를 작성한다면 의미없는 코드를 생성하게 되고 결국은 나중에 코드의 문제를 찾는데 많은 시간을 들여야 한다는 것이다. 가장 기본 적인 이야기지만 간과하는 부분이기도 해서 이야기 하고 싶었다.

이전에 인도 개발자들이 만들어 낸 코드들 분석하면서, 내가 경험했던 것들인데, 예외 처리를 했기 때문에 문제가 없을 거라는 막연한 믿음보다는 예외처리시에 필요한 코드상에서 처리해 부분(RuntimeException)들과 catch문을 사용할 때도 우선 순위를 생각하면서 정의할 것등을 반드시 숙지해야한다.

무엇보다도 가장 판단하기 어려눈 것은 try-catch문을 아무 생각 없이 중첩해서 사용하는 경우인데, 이 경우는 가독성도 떨어지지만, 예외 처리 코드를 분석하기 매우 어렵기 때무에 되도록이면 피해야 한다.