Spring-boot: Rework ErrorController now that getErrorPath() is unused and server.error.path must be used to configure the error path

Created on 21 Jan 2020  路  12Comments  路  Source: spring-projects/spring-boot

Spring boot: 2.2.2
IDE: Spring Tool Suite

One of the ways to create a custom error page is to create a controller class that implements ErrorController. By overriding the getErrorPath() method and returning /error, I am able to return the expected my custom error page (located at resources/templates/customError.html).

But when I return another path, other than /error, I get the following error:

This localhost page can鈥檛 be found. No webpage was found for the web address: http://localhost:8080/bruce

Why is that so.

@Controller
public class MyErrorController implements ErrorController{

 // @RequestMapping("/error")
    @RequestMapping("/error1")
    public String handleError() {
        return "customError";
    }

    @Override
    public String getErrorPath() {

        //return "/error"; 
        return "/error1"; 
    }
}

Interestingly, I have done another experiment. The getErrorPath() returns /error1 , but I change the RequestMapping annotation to @RequestMapping("/error"), and that really return customError.html. This seems to imply that the path return by getErrorPath() is ignored.

enhancement

All 12 comments

I have a feeling that the interface is unnecessary since Spring Boot 2.0, but I need to double check. I think that setting the server.error.path property is now the only way to customize the actual error path.

If I remember correctly, we used to use ErrorController to allow us to configure security, but we substantially simplified that in Spring Boot 2.0.

Hi, thanks for the response.
If that is the case, do we still need to implements ErrorController class, since server.error.path in the properties file is sufficient to achieve what we want.

I don't think so, but I've not had time to confirm for sure yet.

We don't call getErrorPath() anywhere, however implementing ErrorController is required at the moment to cause the auto-configuration of Boot's BasicErrorController to back off:

https://github.com/spring-projects/spring-boot/blob/2725264be167617a194af51e46ec54e2f126f25b/spring-boot-project/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/web/servlet/error/ErrorMvcAutoConfiguration.java#L106-L112

I'm not exactly sure what we should do here. An ErrorController marker interface with no methods feels like a bit of a smell, but it does provide a way of identifying the user's error controller and getting the auto-configured one to back off. I can't really think of a better alternative.

For 2.3.x we could deprecate getErrorPath() and make it a default method so that it doesn't have to be implemented.

ErrorController is currently a @FunctionalInterface. We can't add a default implementation for getErrorPath() without removing @FunctionalInterface, which could break backward compatibility if users are creating lambda expressions using ErrorController.

@scottfrederick After 1caca6e we can't build projects with "-Werror" flag, because we must implement getErrorPath(), but method is deprecated

getErrorPath() in org.springframework.boot.web.servlet.error.ErrorController has been deprecated

Compilation failure [ERROR] /.../.../CustomErrorController.java: warnings found and -Werror specified

version 2.3.0.RELEASE

@siller174 If you want to compile with -Werror you should suppress the deprecation warning using @SuppressWarnings.

I have a feeling that the interface is unnecessary since Spring Boot 2.0, but I need to double check. I think that setting the server.error.path property is now the only way to customize the actual error path.

If I remember correctly, we used to use ErrorController to allow us to configure security, but we substantially simplified that in Spring Boot 2.0.

But ErrorController require the deprecated getErrorPath function. When remove says:

CustomErrorController is not abstract and does not override abstract method getErrorPath() in ErrorController

What is the best alternative?

@WHK102 If you provide your own ErrorController implementation, you'll need to implement the getErrorPath method. It can return null or anything you want it to, the return value will be ignored. It's unfortunate, but it's the best option without breaking backward-compatibility of the API.

@wilkinsona According to this configuration, how to return json instead of a template path when a 404 error occurs

@xwpongithub Sorry, I don't see the connection between this issue and your question. Also, as mentioned in the guidelines for contributing, we prefer to use GitHub issues only for bugs and enhancements. Please use Stack Overflow or Gitter for questions like this.

Was this page helpful?
0 / 5 - 0 ratings