Correct error-page usage in web. xml

The Code of other teams in review recently found that error-page is not used very well.

Their definitions of error-page in web. xml are as follows:

<!--errorpage handler -->        <error-page>            <error-code>404</error-code>            <location>/WEB-INF/jsp/errors/error.jsp</location>        </error-page>        <error-page>            <error-code>500</error-code>            <location>/WEB-INF/jsp/errors/error.jsp</location>        </error-page>        <error-page>            <error-code>414</error-code>            <location>/WEB-INF/jsp/errors/error.jsp</location>        </error-page>        <error-page>            <error-code>505</error-code>            <location>/WEB-INF/jsp/errors/error.jsp</location>        </error-page>        <error-page>            <error-code>400</error-code>            <location>/WEB-INF/jsp/errors/error.jsp</location>        </error-page>

It seems that almost all common server exceptions are covered. If these exceptions occur, the error. jsp page appears.

But is that enough? Obviously, it is not enough. If you read their code carefully, you will find that many of their exceptions may be thrown out and cannot be properly handled.

For example, the fromHomeAddress () method of their CheckoutAddress class is as follows:

public static CheckOutAddress fromHomeAddress(HomeAddr homeAddr) {        CheckOutAddress address = new CheckOutAddress();        address.setAddressId(String.valueOf(homeAddr.getId()));        address.setCountryId(String.valueOf(homeAddr.getCountry().getId()));        address.setCountryName(homeAddr.getCountry().getRegionName());        address.setDetailAddress(homeAddr.getDetailAddress());        address.setFirstName(homeAddr.getFirstName());        address.setLastName(homeAddr.getLastName());        address.setIsDefaultAddress(String.valueOf(homeAddr.getIsDefault()));        address.setMobilePhone(homeAddr.getMobilePhone());        address.setCountryPhoneCode(homeAddr.getCountryPhoneCode());        address.setZipCode(homeAddr.getZipCode());        return address;    }

Obviously, this method does not properly handle exceptions, because the incoming homeAddr input parameter may be null. If so, all vertex operators will throw NullPointerException, obviously, there is no control over the input parameters, and no exception is handled in the code. I have checked that no methods to call this method have handled the exception. Therefore, if a real application encounters a blank homeAddr location after it goes online, the code will throw an exception and will not continue. The result without proper processing may be disastrous, front-end users are overwhelmed by a large piece of abnormal text.

Of course, the best solution for this code is to strictly control the input parameters, and directly handle exceptions in the Code. The so-called "do not throw them to superiors if you can handle them yourself", of course, to prevent this problem, we still have to go to the web. define an error-page option in xml to check the final mark, that is, even if this exception occurs, the error page is displayed, instead of an uncontrollable page.

Therefore, we need to add an error-page element in web. xml, as follows:

<error-page>   <exception-type>java.lang.NullPointerException</exception-type>   <location>/WEB-INF/jsp/errors/error.jsp</location></error-page>

In this way, the application is more robust.

This article from "parallel line cohesion" blog, please be sure to keep this source http://supercharles888.blog.51cto.com/609344/1338856