Debugging JSP errors

Few processes execute as smoothly as originally planned. Nowhere is this more true than in the world of programming. Even unseasoned programming novices know that programming errors and the debugging needed to locate and repair such errors are part of the job.

After encountering and handling JSP errors, you must track down the root cause of the error. This page discusses some effective techniques for debugging your JSP pages. You'll read about the straightforward methods, such as writing to a log, and the not-so-straightforward, such as creating a custom debugging class.

Examining a JSP Error

The laws of thermodynamics state that energy cannot be created or destroyed; it can only be transformed from one form into another. You can make an analogous statement about JSP creation. Yes, JSPs do lots of work for you.

Think of all that effort — or energy — you can save by not having to code servlets to generate dynamic content. However, work not done by you is transferred to the JSP translator. The JSP translator performs the task of changing the JSP page into a servlet. While this process simplifies your development work, it can also, at times, make the source of an error in a JSP more difficult to find.

JSPs get translated into servlets. Often, your diagnostics will refer to activity in the generated servlet. For this reason alone, you should have a good handle on Java servlets to make advanced JSP development go more smoothly.

Although JSPs are touted as a Web page designer's tool, a JSP author will have an extremely difficult time tracking down errors if he or she doesn't have a programming background or the help of somebody with one.

<% double loBound = getBound( request.getParameter( "lobound" ) ) ; %>

Most JSP-enabled servers have an option that allows you to save the generated source code. Hunt that option down and switch it on now. You'll have a hard time finding and solving problems unless you can see the actual generated servlet source code.

JSP pages usually generate HTML, possibly combined with Javascript, that is returned to the client's browser. Any page with more than one programming languages can be quite confusing to read. Finding errors in these situations can be challenging.

Your JSP pages may be generating HTML or scripting code that contains errors. Given the interesting ways different browsers render HTML, you can have resulting pages that render properly on one browser but fail to render on a different browser.

While multiple clients may access the same JSP pages, concurrent access opens up a set of debugging issues. During debugging, you'll need ways of identifying different clients and different threads.

Please note that we offer fully supported JSP Hosting.

Tracking JSP Errors

JSP processing involves several steps, using several different software tools. An error encountered in using any of these tools may be difficult to track down. In the following sections, I will discuss using the JSP page directive attributes errorPage and isErrorPage to handle errors. I also cover the differences between JSP translation errors, which are coding mistakes, and runtime errors, which may or may not be coding mistakes.

Recall that JSPs use the page directive to set properties of the JSP by way of assigning values to attributes. Two attributes of the page directive especially applicable to JSP debugging are errorPage and isErrorPage.

Also, the JSP implicit object called exception is useful in handling JSP errors. Let's go ahead and look at the use and importance of errorPage, isErrorPage, and exception next.

The errorPage Page Directive Attribute

The errorPage attribute names a JSP page that handles exceptions not handled in the current page. In the following coding example, the errorPage attribute is a relative URL.

<%@ page errorPage="mydir/myErrorPage.jsp" %>

The virtue of using custom error pages is that your JSP code is not cluttered with handling errors. (Remember that one of the design goals of JSPs is to separate business logic from presentation details.)

Code that handles errors, a business logic activity, should not be intermingled with code to handle the presentation. The actual reporting of the error is not done within the page containing the page directive with the errorPage attribute set.

Instead, the reporting is done in the JSP page named as the errorPage, or the value of the errorPage attribute. The page mentioned should itself use the isErrorPage attribute. Before showing an example of the errorPage attribute in action, let's first take a look at the isErrorPage attribute.

The isErrorPage Page Directive Attribute

The isErrorPage attribute identifies a JSP page to handle errors. The coding is straightforward:

<%@ page isErrorPage="true" %>

The isErrorPage attribute defaults to false. The JSP examplex.jsp, for example, generates a table of square and cube roots based on the request parameters lobound and hibound. The JSP page directs errors not caught in the page to an error page.