@ExceptionHandler
It is an annotation which can be used in controller methods for having a tighter control of exception handling within a single controller. Methods which are annotated with this annotation will be called when the controller methods throws appropriate exceptions, but it will only applicable to this declare controller. Listing 14-18 shows usage of ExceptionHandler annotation in a typical controller class.
Listing 14-18. Usage of ExceptionHandler annotation in controller class
|
1 2 3 4 5 6 7 8 9 10 11 |
@Controller public class SampleController{ //… @ExceptionHandler public String handleDatabaseException(DataAccessException ex){ return "dbError"; } @ExceptionHandler public void handleOtherError(InvalidBusinessException ex){ } } |
As you can see in Listing 14-1 above, the method signature can be flexible and you have provision to use conventions.
Message Source
Spring resolves all messages which are parameterized and internationalized using MessageSource interface as shown in Listing 14-19 below.
Listing 14-19. MessageSource interface definition
|
1 2 3 4 5 6 7 8 9 10 |
package org.springframework.context; import java.util.Locale; public interface MessageSource { String getMessage(String code, Object[] args, String defaultMessage, Locale loca le); String getMessage(String code, Object[] args, Locale locale) throws NoSuchMessageException; String getMessage(MessageSourceResolvable resolvable, Locale locale) throws NoSuchMessageException; } |
The messages are loaded from properties file in which they are represented in dot natation as shown below:
|
1 |
page.something.property=Text to be displayed |
While using Spring’s default MessageSource, the property files are loaded according to the user’s Locale. It looks for locale specific properties file (mypage_es.properties – Spanish Locale) initially and then it looks the English version properties file (mypage_en.properties) and as a fall back look into property file which doesn’t specify any Locale (mypage.properties).
For most part of your application to work, using default MessageSource implementations provided by Spring Framework should suffice. But, if you would like to pull and resolve the messages from different source, you can write your own MessageSource implementation doing what is required for your application.
There are various built-in MessageSource implemenations provided by the Spring Framework. Some of which are given below:
- springframework.context.support.ResourceBundleMessageSource – It uses underlying JDK’s ResourceBundle implementation in association with standard message parsing provided by MessageFormat to accesses resource bundles using specified base names for resolving the messages.
- springframework.context.support.ReloadableResourceBundleMessageSource – similar to ResourceBundleMessageSource but in contrast supports reloading of properties file through the “cacheSeconds” setting and also through programmatically clearing the properties cache from the application end. This is considered to be faster compared to ResourceBundleMessageSource which might be a bit of surprise looking at the implementation details.
- springframework.context.support.StaticMessageSource – simplest MessageSource implementation which allows messages to be registered programmatically. Supports basic internationalization and are basically used for testing purposes.
Page Visitors: 7770
Tomcy John
Latest posts by Tomcy John (see all)
- A Guide to Continuous Improvement for Architects - February 2, 2023
- Cloud-first Architecture Strategy - January 26, 2023
- Architecture Strategy and how to create One - January 24, 2023