Last week, we had the author of TDD for a Shopping Website LiveProject. Friday at 11am Ranch time, Steven Solomon will be hosting a live TDD session just for us. See for the agenda and registration link

Michael Witherspoon

Greenhorn
+ Follow
since Apr 02, 2005
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Michael Witherspoon

Experimentation is the key. It turns out that I'm wrong, too. There's more than meets the eye as always seems to be the case in J2EE stuff.

My rant that the implicit exception object is ALWAYS null when the error JSP is loaded due to a mapping in the deployment descriptors is only mostly correct. It is ALWAYS null for HTTP error 404. It just so happens that error 404 is the one most people want to trap for. HTTP error 500 sometimes, maybe even most of the time, has a non-null implicit exception object. The tricky part is that sometimes its null and sometimes it's not.

Trapping for HTTP error 500 in this manner also seems to interfere with error handling for JSPs that have their own JSP error pages declared. It will take much more experimentation to figure out exactly what's wrong and the circumstances under which the 500 error has a null exception object and when it doesn't.

Suffice it to say, if you really want to know how the error handling stuff in JSPs works, do a few dozen hours of experimentation because it's nowhere near as clean as people make it out to be.

Finally, sorry for the earlier rant but I'm trying to learn this stuff and I'm getting lots and lots of half-right to mostly wrong answers. It's very frustrating. When those answers come from "experts" I think I'd rather have no answer than wrong ones.

Spoon
After more testing, I've determined that mapping a Java exception to a JSP error page in the deployment descriptors works, too, but mapping and HTML error code still does not.

For example, if the DDs says this:
<error-page>
<exception-type>java.lang.Exception</exception-type>
<location>/error.jsp</location>
</error-page>

the error.jsp can access the implicit exception object. I wish the HTTP error code thing would work, however.
Starting with your original post, there's something you don't know and probably should. In spite of what we all assume to be true about the availability of the implicit exception object when using JSPs as error pages, that object is ALWAYS null if the JSP loads due to being mapped to an error-page element in web.xml.

What I mean is, we assume that if you write
<error-page>
<error-code>404</error-code>
<location>/WEB-INF/errorpages/html404.jsp</location>
</error-page>
in your web.xml, then when a 404 error happens and the html404.jsp JSP loads, the implicit exception object is useful. It's not. It's null, is always null, and will never be anything other than null.

I wish it were otherwise. I also wish the documentation I find at places like java.sun.com where experts pontificate on how one can write the following code into that same html404.jsp and get something useful from the implicit exception object were actually true. It's not. Take this example, for example:

In the html404.jsp file, some people say that you can write this at the top:
<%@page isErrorPage="true" %>
and then automatically gain access to the implicit exception object and so something like this:
<%= exception.getClass().getName() %>

You can, but the only thing you get is the web container exploding all over itself complaining about the exception object being null. Why? Because it is ALWAYS null if the JSP is loaded due to a mapping in the web.xml to an HTTP error code number.

So, why do people write stuff like this? They think but don't test and spew forth "knowledge" without testing. They should test first. If they did they would find out that the only time the implicit exception object is NOT null is when the JSP error page is loaded due to another JSP containing a page directive declaring the error page like this:
<%@ page errorPage="/WEB-INF/errorpages/CustUpdateErrors.jsp" %>

For example, if JSP a.jsp has a page directive like:
<%@ page errorPage="/b.jsp" %>

and b.jsp has a directive like:
<%@page isErrorPage="true" %>

then and only then will the implicit exception object be available with a value other than null.

So, we assume that every JSP error page has a non-null implicit exception object but we are very, very wrong. Only those loaded by another JSP in the manner shown above have one. JSP error pages loaded due to a mapping in the DDs NEVER have a non-null implicit exception object. Oh, yes, the object is there but it's null. If you try to declare a variable for it like:
<% Exception exception %>
you get an error about exception already being declared, so it's definitely there and it's definitely null, and it's definitely useless, and I can't go on anymore about it.

Spoon