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’t 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.

Comment From: philwebb

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.

Comment From: brucebrit

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.

Comment From: philwebb

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

Comment From: wilkinsona

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.

Comment From: wilkinsona

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

Comment From: scottfrederick

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.

Comment From: siller174

@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

Comment From: wilkinsona

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

Comment From: yhojann-cl

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?

Comment From: scottfrederick

@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.

Comment From: xwpongithub

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

Comment From: wilkinsona

@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.

Comment From: nkavian

@wilkinsona I'm saddened by this. The maven-compiler-plugin keeps reporting the deprecation with and without SuppressWarnings, so I can't get it to stop. Eclipse doesn't complain, just maven. I take pride in having clean code and this sucks as my only unresolvable item. Using Spring Boot 2.4.4. when will this deprecation be fully removed?

Comment From: scottfrederick

@nkavian Per the project policy, the method that was deprecated in 2.3.0 has been removed for the upcoming 2.5.0 release.

Comment From: wilkinsona

@nkavian I'm not sure why the compiler that Maven's using (typically javac) wouldn't respect the suppression of deprecation warnings. Until you've upgraded to Boot 2.5, you may also want to try marking your own implementation as @Deprecated.

Comment From: nkavian

Wow, that trick worked! Thanks.

Comment From: brsolomon-deloitte

@nkavian Per the project policy, the method that was deprecated in 2.3.0 has been removed for the upcoming 2.5.0 release.

No mention of this in 2.3 release notes.

https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-2.3-Release-Notes

Comment From: wilkinsona

Thanks, @brsolomon-deloitte. I've updated the release notes to list the deprecation.

Comment From: brsolomon-deloitte

Thanks for doing that @wilkinsona . I have been tasked with bringing an old Java lib kicking and screaming into 2023, so I've learned my lesson here to compile strict and turn deprecation warnings into errors to begin with :)