In a real Java try/catch, the catch argument is the exception object. But with web app error handling, remember, only officially-designated error pages get the exception object. To any other page, the exception just isn’t there. So this does not work:
Using the “var” attribute in <c:catch>
Use the optional var attribute if you want to access the exception after the end of the <c:catch> tag. It puts the exception object into the page scope, under the name you declare as the value of var.
Flow control works in a <c:catch> the way it does in a try block—NOTHING runs inside the <c:catch> body after the exception.
In a regular Java try/catch, once the exception occurs, the code BELOW that point in the try block never executes—control jumps directly to the catch block. With the <c:catch> tag, once the exception occurs, two things happen:
If you used the optional “var” attribute, the exception object is assigned to it.
Flow jumps to below the body of the <c:catch> tag.
Be careful about this. If you want to use the “var” exception object, you must wait until AFTER you get to the end of the <c:catch> body. In other words, there is simply no way to use any information about the exception WITHIN the <c:catch> tag body.
It’s tempting to think of a <c:catch> tag as being just like a normal Java code catch block, but it isn’t. A <c:catch> acts more like a try block, because it’s where you put the risky code. Except it’s like a try that never needs (or has) a catch or finally block. Confused? The point is—learn this tag for exactly what it is, rather than mapping it into your existing knowledge of how a normal try/catch works. And on the exam, if you see code within the <c:catch> tag that is below the point at which the exception is thrown, don’t be fooled.