File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
Win a copy of Clojure in Action this week in the Clojure forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

sendRedirect and IOExceptions

 
Joel Klein
Greenhorn
Posts: 2
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This is a defensive programming question. I'm using HttpServletResponse's sendRedirect method, and everything works great. But I want to handle the possible IOException that sendRedirect might throw. Does anyone know what sorts of things can cause an IOException in sendRedirect?

And more importantly, how the servlet should handle it in terms of server/browser interaction? Is there an accepted best practice? The options I can think of are

1. The servlet does nothing. In this case does the servlet container return anything at all to the browser? (I can check this I suppose.)

2. Servlet sets an error code in the response object. At least this way the browser gets some kind of response.

3. Servlet forwards or redirects to a simple static error page. But here I wonder if the same types of problems causing the original IOException can cause this fallback to fail too.

4. Servlet generates an error page on-the-fly by writing text directly to the request object's input stream. This seems the safest and user-friendliest fallback mechanism.
 
Bear Bibeault
Author and ninkuma
Marshal
Pie
Posts: 64183
83
IntelliJ IDE Java jQuery Mac Mac OS X
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I generally use (4) for all exceptions generated by a web application.

I define a servlet in the web.xml deployment descriptor to handle exceptions. It performs logging of the error and stack trace for the benefit of the programmer, then forwards to an appropriate JSP page for presenting a user-facing "oops!" page to the user.
 
Ben Souther
Sheriff
Posts: 13411
Firefox Browser Redhat VI Editor
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Also keep in mind: a lot of the mechanics of a redirect happen outside of the control of the server. Redirects send a 30x header to the browser with an address. If the browser, firewall, or anything else doesn't want to cooperate, you may never get the next request.
 
Joel Klein
Greenhorn
Posts: 2
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Bear Bibeault:
I generally use (4) for all exceptions generated by a web application.

I define a servlet in the web.xml deployment descriptor to handle exceptions. It performs logging of the error and stack trace for the benefit of the programmer, then forwards to an appropriate JSP page for presenting a user-facing "oops!" page to the user.


This is useful, to know about an error handling page feature for the web app. I was able to look up how to do that, now that I know it's possible.

So in web.xml you have the error-page descriptor, something like this:


But then do you have all your page-handling methods declared to throw IOException? And if thrown it would be coming from things like HttpServletResponse's sendRedirect?

I'm still wondering what types of things would cause sendRedirect and the forward to throw IOException. The Javadoc for sendRedirect has the no-brainer comment that IOException is thrown if an input or output exception occurs.

Somehow I think if I knew better why the exception would occur I could decide better how to handle it.

I know it's quite a murky world of opinions out there on how best to handle exceptions. You want to be as user-friendly as possible but don't want to give up (as in "Lazy Programmer, Didn't Handle Exception").
 
I agree. Here's the link: http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic