first, the book (head first servlets & jsp) says, that calling teh method forward of RequestDispatcher will cause an IllegalStateException if the response has already been committed -> namely response.getOutputStream().flush() has been called.
this turns out to have nothing in common with reality.
and that seems to work perfectly. i debugged tomcat a bit, the exception is there, but i see nothing on my screen, just my .jar download window.
however, if the last four lines look like that:
there's a nice exception
org.apache.jasper.JasperException: java.lang.IllegalStateException: getOutputStream() has already been called for this response
that has nothing to do with the explanations from the book (and i'm getting used to that, it's time to change the book) and it does not behave in the same way.
i'm aware, that both situations i created are wrong, but i'm kind of confused by tomcat's behaviour. how can i force tomcat to throw that exception in my face? i'm making a mistake and the container does not inform me. of course, the exception is in the log in both situations.
You got the exception from getOutputStream() because that is called before the JSP tries to write anything so there is no inconsistency. You already got the output stream as a byte stream, not a character stream, JSP wants to use a character stream.
If you had avoided that then you would have gotten the IllegalStateException.
if the app is running at my customer's server and i do not have access to log files, nobody's going to report anything.
If you let an app out of development with that kind of outrageous error, I have no sympathy for you.
Bear Bibeault wrote:So what would you like it to do? Phone you?
Seriously, what are you expecting besides logging and displaying the error?
leave the sarcasm to yourself.
i expect it to show the error on the screen. in the browser. i cannot expect anyone just to track my logs.
David Newton wrote: You already said you were deliberately doing something wrong--why would you deploy that, then?
it's just an example. as i said, i'm aware that writing such code is just wrong. i did it just to show that sometimes the exception is in logs only, not on screen.
what if i deploy some code in which i do not notice an error?
Maciej Drodel wrote:i expect it to show the error on the screen. in the browser. i cannot expect anyone just to track my logs.
That's not a reasonable assumption, though--most people use IE, and IE has "friendly error pages" turned on by default, making many errors disappear, quite outside of your control.
reasonable or not, the project i'm currently developing is just running at the customer's machine and errors are reported when they are visible. what kind of administrator sits there is unfortunately out of my choice. of course, i'd love someone to parse logs looking for some keywords, like exception or error, but simply nobody does it
this is why i really wanted all my errors on screen, so that users can contact me.
What are you doing to prevent them from doing so? Uncaught exceptions that propagate out to the container will be displayed unless you do something to prevent it (though see IE issue mentioned above). Are you catching the exceptions?
Using an error handler declared in the deployment descriptor will let you handle the errors in a consistent and user-facing fashion.
in my system, we're Spring-based, with AOP running all-over the place, so the situation is a bit different. we've got our own error page and either some AOP-based mechanism redirect to it, or we do it manually in an abstract gui-handling class. we extended the default solutions a bit to help us work with portlets more efficiently, so our solution is not a standarized one.
Keep the out.println( ) and flush( ) statements in a try block and catch the IllegalStateException. The exception will be caught. But one thing i don't understand i did not write throws IllegalStateException in my method syntax then why is the container handling this exception ? I did not propagate to it right.