aspose file tools*
The moose likes Cattle Drive and the fly likes doGet exceptions Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » This Site » Cattle Drive
Bookmark "doGet exceptions " Watch "doGet exceptions " New topic
Author

doGet exceptions

Pauline McNamara
Sheriff

Joined: Jan 19, 2001
Posts: 4012
    
    6
Trying to understand the doGet method in it's many forms...
I've seen doGet with this signature:
public void doGet( HttpServletRequest request , HttpServletResponse response )
plus they throw IOException and sometimes ServletException. Yet neither of the doGets from JavaRanchCommon does. I don't get it.
In general, is exception handling with servlets any different that what we've seen so far? I'm not sure I understand when to use try/catch and when to throw - it doesn't seem to be consistent over the examples I've seen.
Where does an exception get thrown to when there isn't a chain of method calls ending up in a main?

:sleepy:
jason adam
Chicken Farmer ()
Ranch Hand

Joined: May 08, 2001
Posts: 1932
LogServlet extends HttpServlet, so LogServlet's doGet() is overriding HttpServlet. One of the rules of overriding and exception handling is that the overriding method can not throw any exceptions that aren't thrown by the overridden method (it can throw subclasses of the exception, and runtime exceptions, however). Throwing no exceptions is a viable choice, since you aren't throwing anything (which doesn't violate the rule)
Clear as mud?
[ January 10, 2002: Message edited by: jason adam ]
Michael Pearson
Ranch Hand

Joined: Mar 11, 2001
Posts: 351
What Jason said, plus...
After looking at the LogServlet source code I noticed:
  • LogServlet overrides HttpServlets doGet and doPost methods
  • LogServlet overloads HttpsServlets doGet and doPost with doGet( PrintWriter , CastMap ) and doPost( PrintWriter , CastMap).


  • If you override the standard doGet( req , rsp ) and doPost( req , rsp ) methods you wipe out the code that provides the logging functionality of the LogServlet.
    I don't think the exception handling is any different with Servlets than with other Java classes. In this special case the exception handling has been hidden from you.
    Look at the JavaDoc:
    LogServlet JavaDoc
    Where does an exception get thrown to when there isn't a chain of method calls ending up in a main?

    I'm not sure I know, but it seems like the Application Server container catches it and displays either a generic error page or redirects to a registered error page.
    Mike
    [ January 10, 2002: Message edited by: Michael Pearson ]
    Lance Finney
    Ranch Hand

    Joined: Apr 26, 2001
    Posts: 133
    Originally posted by Pauline McNamara:
    Where does an exception get thrown to when there isn't a chain of method calls ending up in a main?

    The exception returns to the Application Server. If you catch an exception in a servlet an run exception.printStackTrace(), the trace is printed out to the screen from which you launched orion. This is the same screen any System.out.println() statements will print to.
    This is the default behavior, although the output can be redirected to a log.
    Michael Matola
    whippersnapper
    Ranch Hand

    Joined: Mar 25, 2001
    Posts: 1746
        
        2
    What the others said, plus...
    I'm pretty fuzzy on the exception-handling bits of servlets, so I'll take a shot at responding to

    Trying to understand the doGet method in it's many forms...

    One thing that the LogSerlvet class does is simplify writing doPost() and doGet() methods for your servlets by providing some boilerplate code and an alternate interface.
    As you've noticed, the standard API versions of doGet() and doPost() have signatures like this:
    public void doPost( HttpServletRequest req , HttpServletResponse resp ) throws ServletException, IOException
    {
    }
    Whenever you subclass HttpServlet and override these methods to write output to a browser, you pretty much have to have the following 4 steps:
  • Set the content type of the HttpServletResponse instance to "text/html."
  • Get a PrintWriter instance from the HttpSerlvetResponse instance.
  • Send text to the PrintWriter instance by issuing print/ln() statements.
  • Close the output stream.


  • Check the source of LogSerlvet and you'll find these steps.
    doPost()
  • Line 218
  • Line 221
  • No default text output provided (or, secretly hiding and waiting at line 225).
  • Line 231


  • doGet()
  • Line 254
  • Line 349
  • No default text output provided (or, secretly hiding and waiting at line 353).
  • Line 359


  • Look again what happens at lines 225 and 353. There's a call to the weirdo LogServlet versions of doPost() and doGet(), with the PrintWriter instance and a CastMap instance passed in. (The CastMap instance just provides an alternate, easier-to-use interface for getting at the parameters held by the HttpServletRequest object.)
    doPost( out , parms ); // Line 225
    doGet( out , parms ); // Line 353
    But the default implementation does nothing.
    protected void doPost( PrintWriter out , CastMap parameters )
    {
    }
    protected void doGet( PrintWriter out , CastMap parameters )
    {
    }
    Well what does all this add up to? Essentially, LogServlet overrides the standard doGet() and doPost() methods that get called by the application server and take care of some of the mundane housekeeping tasks. If you want to take advantage of this, all you do is subclass LogServlet and override the weirdo versions of doPost() and doGet(). In the case of a browser post or get being issued to an instance of your servlet, the application server will call the standard API versions of doPost() and doGet(), which in turn will call the weirdo versions that you've overwritten.
    Note that both calls to the weirdo versions of doPost() and doGet() (lines 225 and 353) are enclosed in try/catch blocks, with Exception being caught. So, more or less any exception (except runtime exceptions?) your code throws will be caught by default in the LogServlet versions of doPost() and doGet(). If you're OK with that, then you don't need to handle the exceptions in your versions of doPost() and doGet().
    Now my question is this -- In the API versions of doPost() and doGet(), the request is the first argument and the response is the second argument. "PrintWriter out" is something kinda responsey, and "CastMap parameters" is something kinda requesty. So why did the author of LogServlet switch the order round? Paul?
    I use the light-hearted "weirdo" with the utmost respect...
    [ January 10, 2002: Message edited by: Michael Matola ]
    Marilyn de Queiroz
    Sheriff

    Joined: Jul 22, 2000
    Posts: 9044
        
      10
    catch ( Exception e ) also catches runtime exceptions as well as compile time exceptions.


    JavaBeginnersFaq
    "Yesterday is history, tomorrow is a mystery, and today is a gift; that's why they call it the present." Eleanor Roosevelt
    jason adam
    Chicken Farmer ()
    Ranch Hand

    Joined: May 08, 2001
    Posts: 1932
    Hey Mike, is CastMap an example of a Decorator? (starting OOAD classes, looking for patterns everywhere now )
    Michael Matola
    whippersnapper
    Ranch Hand

    Joined: Mar 25, 2001
    Posts: 1746
        
        2
    My thought-about-this-for-five-minutes response is that no, it's not a decorator.
    CastMap extends HashMap, so it's a direct subclass. Part of the point of decorator is that it's an alternative to subclassing and the decorator delegates requests to the object it's holding.
    Using CastMap just provides an alternate data structure (Map) to the usual Enumeration (think Iterator), Map, or String array you'd get from HttpServletRequest. Note that putting the parameter names and values into a CastMap (see LogServlet's getParms()) does make the assumption that each parameter name has only one corresponding value.
    If CastMap corresponds to any GoF pattern, I'm not seeing it. (Took a look at adapter and facade, but I'm not really comfortable with those. Actually, there are only a couple of patterns I'm comfortable with.)
    Does look pretty close to what Martin Fowler calls a Local Extension.
    (If you're looking for decorators in the com.javaranch.common stuff, maybe try DataPool.Wrapper. (But I'm not clear why that class was done as a wrapper of Object instead of a just at subclass of Object.))
    [ January 11, 2002: Message edited by: Michael Matola ]
    jason adam
    Chicken Farmer ()
    Ranch Hand

    Joined: May 08, 2001
    Posts: 1932
    Ok, think I undestand that. I'm not comfortable with any of them yet (except Singleton), its a level of abstraction that I'm just starting to get into. Exciting stuff, though!
    Jason
    Michael Matola
    whippersnapper
    Ranch Hand

    Joined: Mar 25, 2001
    Posts: 1746
        
        2
    Originally posted by Michael Matola:
    (But I'm not clear why that class was done as a wrapper of Object instead of a just at subclass of Object.))

    Well, that was one of the dumber things I've said in public in recent memory. Of course I understand why it has to be a wrapper.
    Michael Matola
    whippersnapper
    Ranch Hand

    Joined: Mar 25, 2001
    Posts: 1746
        
        2
    Regarding comfort levels with patterns. I've got a grasp on singleton, template method, observer, iterator. (Easy ones.) Kinda murky on state/strategy and factory stuff. The rest, not really. I think you have to read and write a lot more OO code than I have to start seeing some of these.
    I definitely want to take a look at Design Patterns Explained, which everybody seems to be talking up, but I have a few other things to work through first.
    paul wheaton
    Trailboss

    Joined: Dec 14, 1998
    Posts: 20529
        ∞

    Marilyn e-mailed me and asked me to respond to this:
    Now my question is this -- In the API versions of doPost() and doGet(), the request is the first argument and the response is the second argument. "PrintWriter out" is something kinda responsey, and "CastMap parameters" is something kinda requesty. So why did the author of LogServlet switch the order round? Paul?

    That's a damn good question. I suppose that maybe I should have done it the other way. However, my reasoning goes back to the old and moldy days of C++ where I was a big fan of default parameters.
    In this case, the "out" cannot be a default parameter - you have to write something out! But! The "parms" is optional. There are all sorts of servlets you could write that take nothing in, but provide stuff out (time of day, current stock values, current inventories, etc.).
    To java-fy this, I could at some point make another method that has only "out". Of course, in java, I could have maintained the order.
    If you and I were in a design meeting, I suppose I would probably concede your point.
    But! Here is one last gasp at justification. If all of the javaranch libraries follow the rule of most essential stuff first, what parameters you need does become a bit more predictable for any situation. Therefore, in this case, my way *might* be the right way.
    To answer another question I saw here: this does not follow the decorator pattern because to do that, both the sun stuff and my stuff would need to implement the same interface and the doPost() and doGet() methods would need to have the same signature.


    permaculture Wood Burning Stoves 2.0 - 4-DVD set
     
    With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
     
    subject: doGet exceptions