Table of content

This is a second article from the series about REST Exception handling with Spring. In my previous post I have described how to organise the most simple exception handling in a REST service. This time I will go further and I will show you when you’d better to use exception handling on a @ControllerAdvice level.


Before I will start the technical part of the post, I need to concider a situation when we would better to use an exception handling on a @ControllerAdvice level.
Usually one controller is responsible for entire logic related to one type of entities. That’s mean that if I have some EntityController class, it will contain all CRUD (create, read, update, delete) operations with the entity and maybe some extra logic if it is required. Let’s examine three operations: read, update, delete.

The read operation returns some particular entity depending on ID which we pass to it as an argument. if the entity doesn’t exist the read operation returns null. The update / delete operation updates / deletes a particular entity respectively. And each of these two operations include the read operation, because before an entity will be updated / deleted we need to ensure that it exist in a system.

It’s a normally practice when an entity is not found during the update / delete operation an application will throw an EntityNotFoundException. An exception handling in this case will be very straightforward. The application have to return an information to a client:

  • Response Header: 404
  • A link which caused the exception
  • Error message: There is no Entity with id: N

This is a most simple response structure for a such exceptions. So regardless how many different entity classes you have in an application, because you can handle similar kind of exception (e.g. no such entity) in the same way. This became possible thanks @ControllerAdvice annotation.

Exception handling on @ControllerAdvice level

Practical part of the article will be based on the application form the last tutorial.

Firstly I need to add an error message into the messages.properties file:

error.no.smartphone.id = There is no Smartphone with id: 

After this let’s look on the controller methods which are interesting for us in topic of this article.

	@RequestMapping(value="/edit/{id}", method=RequestMethod.GET)
	public ModelAndView editSmartphonePage(@PathVariable int id) {
		ModelAndView mav = new ModelAndView("phones/edit-phone");
		Smartphone smartphone = smartphoneService.get(id);
		mav.addObject("sPhone", smartphone);
		return mav;

	@RequestMapping(value="/edit/{id}", method=RequestMethod.PUT, 
			produces = MediaType.APPLICATION_JSON_VALUE,
			consumes = MediaType.APPLICATION_JSON_VALUE)
	public Smartphone editSmartphone(@PathVariable int id, 
			@Valid @RequestBody Smartphone smartphone) {
		return smartphoneService.update(smartphone);
	@RequestMapping(value="/delete/{id}", method=RequestMethod.DELETE, 
			produces = MediaType.APPLICATION_JSON_VALUE,
			consumes = MediaType.APPLICATION_JSON_VALUE)
	public Smartphone deleteSmartphone(@PathVariable int id) {
		return smartphoneService.delete(id);

These methods include calls of the SmartphoneService. And implementation of the SmartphoneService contains methods which can throw a SmartphoneNotFoundException.

@Transactional(rollbackFor = { SmartphoneNotFoundException.class })
public class SmartphoneServiceImpl implements SmartphoneService {
	private SmartphoneRepository smartphoneRepository;

	public Smartphone create(Smartphone sp) {
		return smartphoneRepository.save(sp);

	public Smartphone get(Integer id) {
		Smartphone sp = null;
		if (id instanceof Integer)
			sp = smartphoneRepository.findOne(id);
		if (sp != null)
			return sp;
		throw new SmartphoneNotFoundException(id);

	public List<Smartphone> getAll() {
		return smartphoneRepository.findAll();

	public Smartphone update(Smartphone sp) {
		Smartphone sPhoneToUpdate = get(sp.getId());
		return sPhoneToUpdate;

	public Smartphone delete(Integer id) {
		Smartphone sPhone = get(id);
		return sPhone;


Here is a code of SmartphoneNotFoundException:

public class SmartphoneNotFoundException extends RuntimeException {

	private static final long serialVersionUID = -2859292084648724403L;
	private final int smartphoneId;
	public SmartphoneNotFoundException(int id) {
		smartphoneId = id;
	public int getSmartphoneId() {
		return smartphoneId;


And finally I can move to the @ControllerAdvice.

public class RestExceptionProcessor {
	private MessageSource messageSource;
	public ErrorInfo smartphoneNotFound(HttpServletRequest req, SmartphoneNotFoundException ex) {
		Locale locale = LocaleContextHolder.getLocale();
		String errorMessage = messageSource.getMessage("error.no.smartphone.id", null, locale);
		errorMessage += ex.getSmartphoneId();
		String errorURL = req.getRequestURL().toString();
		return new ErrorInfo(errorURL, errorMessage);


The exception handler method returns ErrorInfo object. You can read more about it in the previous post about Exception Handling on a @Controller level.

In this way we can collect all similar exceptions in one place, just by adding extra exception classes into @ExceptionHandler annotation. This approach makes a code maintenance more easier within an entire application.

Demonstration of the example:


Note: I made the request with the id value = 356, but there wasn’t any record in a database which correspond to this id value. This circumstance cause the exception.

In the next article I will concider example of REST Exception handling on a @ControllerAdvice level. The main feature is that all data will be send via form and all error messages will be processed with the help of JQuery.

About The Author

Mathematician, programmer, wrestler, last action hero... Java / Scala architect, trainer, entrepreneur, author of this blog