The 500 page and also the 404 page are pages that are displayed when an exceptional condition is handled by the webapp server itself. In the case of the 404 page, the URL cannot be resolved at all ("Page not found").
The default forms (more precisely the templates) of these pages are actually hard-coded into the webapp server. However you can override them and design your own error pages which you then indicate in your webapps' web.xml config file.
You'd do that mostly as a vanity thing, though, since a well-designed webapp shouldn't be relying on error pages as part of the basic program design. But for people who fat-finger manual URLs you might want some cute alternative 404 page.
An IDE is no substitute for an Intelligent Developer.
posted 1 month ago
Now I think the best way to handle the case when an exception is thrown during filter's doFilter method should be --- just log the error information and let it pass to next filter in filter chain. This should make more sense than send it to 500 error page, right ? See, if we get exception in doFilter, it doesn't mean we shouldn't move on to the next filter.
An exception in a filter usually means a bug in the program, so I don't think your approach is the best course. The best curse would be to figure out why the exception is happening and make sure that out doesn't.
If the web app can operate without the filter being applied, why is the filter there in the fist place?