Pragmatic Programmer Issues – pietrowski.info

In previous version of Spring Framework to handle exception we used HandlerExceptionResolver interface. Spring also provides simple implementations which was suitable in most of cases. Since 3.0 version we have few additional exception resolvers plus we can use annotation to specify our exception handler methods or classes without implementing HandleExceptionResolver interface.

1. AnnotationMethodHandlerExceptionResolver (new in 3.0)
2. ResponseStatusExceptionResolver (new in 3.0)
3. DefaultHandlerExceptionResolver (new in 3.0)
4. SimpleMappingExceptionResolver

SimpleMappingExceptionResolver

Should be configured in XML, there are few properties which drives this resolver behaviors.

• defaultErrorView -> this view name will be returned if no mapping will be found.
• defaultStatusCode -> once the view name was resolved if the view hasn’t status code the defaultStatusCode will be applied.
• statusCodes -> Map with “view name” to “status code” mapping.
• exceptionAttribute -> the name of attribute where exception is hold by default “exception” is used.
• exceptionMappings -> Properties which maps Exception “class name” to “view name”. Watch out as you can easily maps more than you want, this is because only String.contains is checked, so a=viewName mapping will catch all exception with “a” in the name.
  Another thing to consider is that if you provide deep Exception hierarchy (n) and you provide a lot of exception mapping (m), you will end up with O(n*m) lookup algorithm. It may seem not problem, but if somebody spots that (Error page which render time is quite long), than it may be used with DDOS to increase load on ours machines.

DefaultHandlerExceptionResolver

First at all it has pageNotFound logger which is org.springframework.web.servlet.PageNotFound logger category, second it decides what to do depending on exception type, it is base class to extend when we want change default behavior:

• NoSuchRequestHandlingMethodException : no request handler method was found by default it sends 404 error. Override handleNoSuchRequestHandlingMethod.
• HttpRequestMethodNotSupportedException : no request handler method was found for the particular HTTP request method by default 405 error.Override handleHttpRequestMethodNotSupported.
• HttpMediaTypeNotSupportedException : no HttpMessageConverter were found for the PUT or POSTed content by default 415 error. Override handleHttpMediaTypeNotSupported.
• HttpMediaTypeNotAcceptableException : no HttpMessageConverter were found that were acceptable for the client (Accept header) by default 406 error. Override handleHttpMediaTypeNotAcceptable.
• MissingServletRequestParameterException : required parameter is missing by default 400 error. Override handleMissingServletRequestParameter.
• ConversionNotSupportedException : WebDataBinder conversion cannot occur by default 500 error. Override handleConversionNotSupported.
• TypeMismatchException : WebDataBinder conversion error occurs by default 400. Override handleTypeMismatch.
• HttpMessageNotReadableException : HttpMessageConverter cannot read from HTTP request by default 400 error. Override handleHttpMessageNotReadable.
• HttpMessageNotWritableException : HttpMessageConverter cannot write to HTTP response by default 500 error. Override handleHttpMessageNotWritable.

ResponseStatusExceptionResolver

This resolver allows us to use @ResponseStatus annotation. If we annotate our Exception with @ResponseStatus annotation than the response will get status code from annotation.

• ResponseStatus.value as status code (it is HttpStatus enum)
• ResponseStatus.reason as reason or default HttpResponse reason if not set.

AnnotationMethodHandlerExceptionResolver

Last but not least, and from my point of view this resolver is the most important. This exception resolver allows us to use @ExceptionHandler annotation, every method annotated by @ExceptionHandler will become exception handler. As parameters @ExceptionHandler need an array of Throwable. We also should use @ResponseStatus to indicate status code.

The method signatures possibilities are vary so see documentation to get all the proper combinations of parameters and return types.

The idea is pretty simple, for all the ExceptionHandler.value exception the exception -> Method handler is created, when Exception happens Method will be invoked.

Conclusions

Since 3.0 we rather has no need to setup handlers by ourself, the most useful way is to use @ExceptionHandler annotation. By default DispatcherServlet will setup AnnotationMethodHandlerExceptionResolver, ResponseStatusExceptionResolver and DefaultHandlerExceptionResolver as handlers resolvers. So we are ready to start with annotation based approach.

My approach is that I try to create moduleExceptionHandler class which has all methods annotated by @ExceptionHandler (except utility methods of course) and I always annotate them by @ResponseStatus as well. The methods parameters and return type vary depending on my needs. It a little bit central approach but it avoids problem with more than one handler per Exception.

If you need a code, please send me a comment. I’m currently in the process of choosing git repository.

I found some interesting feature in springframework. Spring offers you to map sql error code to exception type. By default there is in springframework distribution file called sql-error-codes.xml which has definition for common databases ( DB2, Derby, H2, HSQL, Informix, MS-SQL, MySQL, Oracle, PostgreSQL, Sybase).

This keys are taken form java.sql.DatabaseMetaData databaseProductName property. Each driver should provide proper implementation. This post will provide you the way how to add another databases or extends definition to more sql codes.

As we read javadoc, the default file is bundled in spring.jar and it’s location is “org/springframework/jdbc/support/sql-error-codes.xml" so first solution is to simple extract this file, add what we want, and than put it back. This solution has many drawbacks e.g. when we upgrade we must repeat our steps once again. If we keep reading javadoc we read

Reads the default file in this package if not overridden by a file in the root of the class path (for example in the “/WEB-INF/classes” directory).

So the second option is to provide file called ‘sql-error-codes.xml’ in the root path. Lets start coding.
Our App.java is very simple.

public class App {
public static void main(String[] args) {
SQLErrorCodesFactory errorCodes = SQLErrorCodesFactory.getInstance();
SQLErrorCodes errorCode = errorCodes.getErrorCodes(“MySQL”);
}
}

If we run this in debug mode we can see something like this. This is default SQL error codes definition for MySQL database. Now we add the ‘sql-error-codes.xml’. I’ve just copied MySQL bean from default file and added some codes to badSqlGrammarCodes. This time the result look like this:

And here is execution log, interesting lines in bold:

Sep 2, 2008 9:54:46 PM org.springframework.beans.factory.xml.XmlBeanDefinitionReader loadBeanDefinitions
INFO: Loading XML bean definitions from class path resource [org/springframework/jdbc/support/sql-error-codes.xml]
Sep 2, 2008 9:54:46 PM org.springframework.beans.factory.xml.XmlBeanDefinitionReader loadBeanDefinitions
INFO: Loading XML bean definitions from class path resource [sql-error-codes.xml]
Sep 2, 2008 9:54:46 PM org.springframework.beans.factory.support.DefaultListableBeanFactory registerBeanDefinition
INFO: Overriding bean definition for bean 'MySQL':
    replacing [Generic bean: ... defined in class path resource [org/springframework/jdbc/support/sql-error-codes.xml]]
    with [Generic bean: ...  defined in class path resource [sql-error-codes.xml]]
Sep 2, 2008 9:54:46 PM org.springframework.jdbc.support.SQLErrorCodesFactory
INFO: Found custom sql-error-codes.xml file at the root of the classpath
Sep 2, 2008 9:54:46 PM org.springframework.jdbc.support.SQLErrorCodesFactory
INFO: SQLErrorCodes loaded: [DB2, Derby, H2, HSQL, Informix, MS-SQL, MySQL, Oracle, PostgreSQL, Sybase]

The point to remember is that our definition didn’t override all the definition but only definition with the same bean id. This is not so clear in SQLErrorCodesFactory javadoc, which suggest that we override all beans.

We can use this mechanism if we have different database, or if we want to extend or change sql code mapping to exception. The application is really simple but you can
download it, and try by yourself.

Bye.

There is a possibility to configure spring framework only in java. Yep no XML .

There is a project spring-java-config. This project aims to provide a way to configure spring without XML. To use it with maven you should add repository to your pom and dependency

<repository>
  <id>spring-milestone</id>
  <name>Spring Milestone Repository</name>
  <url>http://s3.amazonaws.com/maven.springframework.org/milestone</url>
</repository>

<dependency>
   <groupId>org.springframework.javaconfig</groupId>
   <artifactId>spring-javaconfig</artifactId>
   <version>1.0.0.m3</version>
</dependency>

One thing to mention is to setup java 5 compiler, because spring java config use annotation.

  <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <configuration>
      <source>1.5</source>
      <target>1.5</target>
      <encoding>UTF-8</encoding>
    </configuration>
  </plugin>

This config will provide as all the dependencies, we can start to configure our beans. The class which has bean configuration must be annotated by @Configuration annotation, and methods with @Bean annotation is equivalent to element. Resume : klas with @Configuration equals xml file with beans, and method with @Bean equals element.

And the last thing is to use JavaConfigApplicationContext which accepts as constructor class annotated with @Configuration property. Below the main class.

And this is basis, we can probably stop here but I provide some additional information. Depends on method visibility our bean is visible or not in the context.

• The standard set of *Aware interfaces are supported.
• You can use scopes, autowire and others features known from xml configuration
• @Import is equivalent of xml’s <import>, and JavaConfigApplicationContext accepts more than one class as constructor parameter.
• For web application we can use JavaConfigWebApplicationContext

I’m still watching the future of the project. Stay tuned