This content has been marked as final. Show 6 replies
You'll have to do things differently as the way you've chosen now simply does not work. You can't generate a response (meaning data is already sent to the client / browser) and then half-way through decide that you want to do something else - HTTP does not work that way. One request, one response. So if you really must redirect to an error page you had better make sure that you can do that before you decide to start dumping data to the client.
Note that your description is a bit vague, so it may just be that I misunderstand the order of things as they are happening.
Handling errors in the response-rendering phase is a bit tricky. Wonder if cacheing the reponse (either by configuration or by writing to a bytebuffer or something) until you're sure everything is OK could work?
I hope to better explain.
In my JSF code I have the next:
In the listBeanRequest class, the method getElements() has a line, Integer h = Integer.valueOf("a");, which efforts the java.lang.NumberFormatException
An in my web.xml I have:
I'm using JSF 1.2 running on Apache Tomcat 6
Yes - redesign you code such that the getElements() no longer throws an exception. You could try by creating a @PostConstruct annotated method in which you initialize the elements up front and deal with exceptions there, but don't delay it until the moment where the page is already rendering.1 person found this helpful
And could it work the next tag in web.xml?
Not for your particular problem, for the reasons I already explained. You cannot magically start a new response when one is already "committed" - the server can't do it for you either.
This is really the moment where you have to understand the WHY, which you can figure out by Googling for the "response has already been committed" exception message.