File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes JSP and the fly likes Error Handling and the Response Object Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » JSP
Bookmark "Error Handling and the Response Object" Watch "Error Handling and the Response Object" New topic
Author

Error Handling and the Response Object

Winston Smith
Ranch Hand

Joined: Jun 06, 2003
Posts: 136
So, I'm finding myself venturing deeper into the dark caverns of JSP, exploring the wealth of features that have seduced me into becoming a true believer and supporter of JSP for advanced web applications. What am I, a salesman? Is anyone from Sun reading this? Anyhow, my point is, I've recently been playing around with the implicit response object, in particular, passing this object to a Bean method. The situation is as follows:
I'd like to centralize error control for our web application. To do so, I've created an ErrorControl bean. Now, the whole purpose of centralizing the error control is to provide an elegant means of informing the user of:
  • what happened
  • where the error occurred
  • and what to do next

  • This is relatively easy in a stand-alone app, but once you're in the web environment, it gets a little more intense. So, I'm using this ErrorControl bean to process the error, generate informative messages, and, most importantly, redirect the user to the proper page.
    To do this, I've passed the implicit reponse object into a method as follows:

    So, in the handleError() method, I redirect the user to the proper page. This works fine.
    The only thing I don't like is, I have to pass the response object into the method with each call. I cannot simply have a class attribute of type HttpServletResponse, set it once, and use it throughout the client's session. This makes sense, since the response object naturally needs to change as the client changes pages, but how exactly does this work? It is the same object, true? What changes in the response object? What's going on behind the scenes with this object as new requests are generated from the client?
    Sorry for the lengthy post, but I'm interested to know because being able to pass around this response object can be a powerful feature.
    Thanks,
    WS
    [ March 26, 2004: Message edited by: Winston Smith ]
    [ March 26, 2004: Message edited by: Bear Bibeault ]

    for (int i = today; i < endOfTime; i++) { code(); }
    Bear Bibeault
    Author and ninkuma
    Marshal

    Joined: Jan 10, 2002
    Posts: 60990
        
      65

    The response object is a context object whose lifetime is valid only for the duration of the single request for which it models the response. As such, and as you have discovered, it makes no sense to try to store a handle to it across requests.
    And it shouldn't.
    The reason that you are seeing limitations that do not actually exist is that you are circumventing, or at best, ignoring, the built-in error handling provided by the servlet specification.
    How are you detecting the error conditions? I'm guessing with on-page try/catch blocks? Not the best way to do this.
    What you should be setting up is an error handling servlet (rather than a bean) that you declare in the web.xml file to handle all exceptions (you can even declare different servlets for different exceptions, but I don't see that done a whole lot). This servlet will be automatically invoked when any unhandled exception is thrown from a page or other servlet. Since the currrent request and response objects are passed to this error handler, you always have all the info you need at your fingertips to be able to process and deal with the error in whatever manner is appropriate.
    This approach is easy and tight. It follows the expected workings of the servlet specification, and it eliminates the need for any error handling goop on the pages.
    Your bean approach strikes me as inside out. You are trying to handle the error from "outside" rather than letting the servlet engine do most of the work for you.
    [ March 26, 2004: Message edited by: Bear Bibeault ]

    [Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
    Bear Bibeault
    Author and ninkuma
    Marshal

    Joined: Jan 10, 2002
    Posts: 60990
        
      65

    P.S. I augmented your topic title to better match the subject of the topic.
    Winston Smith
    Ranch Hand

    Joined: Jun 06, 2003
    Posts: 136
    Yes, indeed my technique may look like that of an unshaved, caffeine-starved programmer waking up with an early morning hangover. Servlets are my weak point, so on that topic, I'll need to devote some more attention. But the reason this all came about was because I have numerous Beans, calling methods, which in turn call other methods, and so on (cohesion, cohesion, cohesion...I hear my dear old professor say). Now, an exception may occur within one of these methods, and if so, I want to know exactly where it occured (i.e. class and method), so I catch it, and pass the info back up the method-trace until it ultimately gets back to the the JSP page, where it is handled appropriately, providing the user with a somewhat friendlier version of the error reports we're all used to (the maintainers are not Java folks, so error reporting needs to be as clean as possible).
    If I go the Servlet route, other than printing a stacktrace, how will I know exactly where the exception occurred?
    My model, as it is now, currently holds each individual method responsible for exception handling, so all exceptions are caught within the local methods themselves. If I abstract this, and move the exception handling further up the method trail, don't I lose the ability to localize the source of the exception?
    WS
    Bear Bibeault
    Author and ninkuma
    Marshal

    Joined: Jan 10, 2002
    Posts: 60990
        
      65

    don't I lose the ability to localize the source of the exception?

    Other than the stack trace, what more info could you need to know where the exception occurred?
    Winston Smith
    Ranch Hand

    Joined: Jun 06, 2003
    Posts: 136
    We were trying to get away from a stack trace, and provide the user with a cleaner error message (some users cower in fear when presented with the dirty underbelly of a java program gone wrong). But, as you can see by the description of our technique, we may have been implementing an error control scheme at the expense of good programming structure. So, my question has become one of design--where exactly should exceptions be dealt with when in a JSP environment? Are try / catches not a good design? Should exceptions be thrown and dealt with by the JSP errorPage alone?
    Thanks,
    WS
    Bear Bibeault
    Author and ninkuma
    Marshal

    Joined: Jan 10, 2002
    Posts: 60990
        
      65

    Nothing I described forces you to show the stack trace to the end user. Once the error handler servlet is invoked (I avoid JSP error pages for this since there's way too much processing going on for it to be a JSP in my books), it can do whatever it wants with the error information.
    Frequently, my user-facing error page contains a generic "We're sorry, but our servers detected a problem" message. Prior to displaying this, the stack trace has been logged somewhere where I can find it to diagnose the problem. Sometimes, the error page contains a form the user can submit to describe their actions at the time of the error.
    My point is, you can use the built-in error handling capabilities of the servlet engine without having to display scary stack traces to the end user, and without sacrificing any diagnostic capabilities.
    Winston Smith
    Ranch Hand

    Joined: Jun 06, 2003
    Posts: 136
    Thanks for the input. I'm going to hit the books and find out more on servlet error handling.
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Error Handling and the Response Object