LearnAI ToolsCareerPractice BuildsPlayContact
Lesson 2118 min read

Error Handling in JSP

Learn how to handle exceptions gracefully in JSP using the errorPage and isErrorPage directives, and build a custom error page.

Introduction

Left unhandled, an exception in a JSP page results in an ugly stack trace shown directly to the user — a poor experience and a potential information leak. JSP gives you a clean, declarative way to catch that: point a page at a dedicated error page, and the container automatically forwards there whenever an uncaught exception is thrown.

What You Will Learn
  • How the errorPage directive routes exceptions to a friendly page.
  • How isErrorPage unlocks the implicit exception object.
  • How to build and use a custom error page.
  • How to configure error handling globally in web.xml.

The errorPage Directive

Adding errorPage to a page directive tells the container: if any uncaught exception escapes this page, forward the request to the named page instead of showing a raw stack trace.

<%@ page errorPage="error.jsp" %>
<%
int[] numbers = { 1, 2, 3 };
int value = numbers[5]; // throws ArrayIndexOutOfBoundsException
%>
<p>Value: <%= value %></p>

The isErrorPage Directive

The target page must declare itself as an error page with isErrorPage="true". This single flag unlocks the implicit exception object, which is otherwise not available on ordinary pages.

<%@ page isErrorPage="true" %>
<h2>Something Went Wrong</h2>
<p>We hit an unexpected error. Our team has been notified.</p>

The exception Implicit Object

On a page marked isErrorPage="true", the implicit exception object gives you the actual Throwable that was thrown, useful for logging or, in development, displaying details.

<%@ page isErrorPage="true" %>
<h2>Something Went Wrong</h2>
<p>We hit an unexpected error. Our team has been notified.</p>
<c:if test="${pageContext.request.serverName == 'localhost'}">
<hr />
<p><strong>Debug info:</strong> ${exception.message}</p>
<pre><% exception.printStackTrace(new java.io.PrintWriter(out)); %></pre>
</c:if>
Rendered Output (Production)

Click Run to see what this code prints.

Never Show Stack Traces to End Users

Stack traces reveal internal package names, file paths, and sometimes even query text — information an attacker can use. Always gate detailed error output behind an environment check like the one above, or omit it entirely in production.

Configuring Errors in web.xml

Rather than adding errorPage to every single JSP, you can register one error page application-wide in web.xml — it applies to any page that does not set its own.

<!-- web.xml -->
<error-page>
<exception-type>java.lang.Exception</exception-type>
<location>/error.jsp</location>
</error-page>

HTTP Status Error Pages

web.xml can also map specific HTTP status codes, like a 404 Not Found, to a friendly custom page — separate from the exception-based error handling above.

<!-- web.xml -->
<error-page>
<error-code>404</error-code>
<location>/not-found.jsp</location>
</error-page>
<error-page>
<error-code>500</error-code>
<location>/server-error.jsp</location>
</error-page>

Common Mistakes

Avoid These Mistakes
  • Forgetting isErrorPage="true" on the target page — the exception object simply will not be available.
  • Showing raw stack traces to end users in production, leaking implementation details.
  • Setting errorPage but never testing that it actually triggers, leaving users to see an ugly default error screen anyway.
  • Only handling exceptions and forgetting HTTP status codes like 404, which are not exceptions at all.

Best Practices

  • Always configure at least one application-wide error page in web.xml as a safety net.
  • Log full exception details server-side even when the user only sees a friendly message.
  • Gate any detailed debug output behind an environment check.
  • Keep the error page itself simple — an error page that also errors leaves the user with nothing.

Frequently Asked Questions

Yes, error-page in web.xml can point to any resource path, including a servlet-mapped URL.

The container falls back to its own default error screen, since there is no further error page configured to catch it.

Yes, any uncaught Throwable that propagates out of the page triggers the configured error page.

Key Takeaways

  • errorPage on a page directive forwards uncaught exceptions to a friendly page.
  • isErrorPage="true" on the target page unlocks the implicit exception object.
  • web.xml can configure error pages application-wide, by exception type or HTTP status.
  • Never expose raw stack traces to end users in production.

Summary

Graceful error handling is what separates a production-ready application from a fragile prototype. With that covered, you have now seen every core piece of JSP individually — the next lesson ties them together by combining servlets and JSP in the classic MVC pattern.

Next Lesson →

JSP with Servlets (MVC Pattern)