> -----Original Message-----
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: 10 June 2001 02:00
> To: [EMAIL PROTECTED]
> Subject: Re: Exception handling in the ActionServlet
>
>
>
>
> On Sat, 9 Jun 2001 [EMAIL PROTECTED] wrote:
>
> > Hi,
> >
> > I would like to catch all of our project specific
> exceptions in one place (as a
> > last resort, if nobody else catches them earlier on) and
> handle them in a
> > generic way. The obvious way to do this, I think, is by overriding
> > processActionPerform in our own <Project>ActionServlet and catch
> > <Project>Exception's (superclass for all our own
> exceptions) there. But the
> > Action.perform method only throws IOException &
> ServletException, so either all
> > our own exceptions will have to inherit from either of
> those two classes (can't
> > be the right thing to do), or I will have to change the
> Action.perform
> > definition to also throw our <Project>Exception's (doesn't
> seem right either,
> > I'd prefer not to have to alter any struts code)?
> >
> > What should I do?
> >
>
> How about having the base class for you project exceptions be
> a subclass
> of ServletException? That way, you can throw it if you really want
> to. Then you could declare an <error-page> element in your
> web.xml file
> to define common handling (if you don't the default will be
> an ugly stack
> trace on most containers).
Alternatively, if you have a project exception in your Action.perform
method, you could just wrap it up in a ServletException and throw that. E.g;
try {
.....
} catch (ProjectException e) {
throw new ServletException("Some text", e);
}
Then in your subclassed processActionPerform method you get at your original
exception by calling the getRootCause() method of ServletException. This
avoids having to base your exceptions on any particular subclass.
>
> > This actually brings me to another problem that doesn't
> have anything to do
> > with struts, but is more a general Java question. Anyway,
> maybe somebody here
> > has an elegant solution to it:
> >
> > Assume the problem above is solved and furthermore that
> some of the project
> > specific exceptions have to inherit from other existing
> exception classes (e.g.
> > ServletException, IOException, etc.). Since we don't have
> multiple inheritance,
> > I can't have a <Project>Exception that is a superclass to
> all my own
> > exceptions. I still want to catch all our own exceptions
> (but no others) in one
> > place. My first though was of course to define a
> <Project>Exception interface
> > and let all our own exceptions implement this interface,
> thus being able only
> > to catch <Project>Exception's. But Throwable is not an
> interface (why not?
> > What's the idea behind this design?) that
> <Project>Exception could inherit from
> > and thus this approach doesn't work, as the try{}catch(){}
> statement expects a
> > Throwable object as parameter
> (try{}catch(<Project>Exception e){} doesn't
> > compile).
> >
> > Well, as a kind of a hack I then thought I'll catch all
> exceptions, check if it
> > is a project specific one
> (<Project>Exception.class.isInstance(anException)),
> > and if not throw it again, but that can't be right, because
> the method where
> > this happens then will have to be declared to throw
> Exception (to generic).
> >
> > I'll appreciate any help, thanks in advance and the best
> satisfactory answer
> > wins a free beer in Zurich ;-)
> >
>
> I'd investigate extending ServletException for your
> application exception
> classes.
>
> Another off-the-wall idea would be to extend RuntimeException
> instead --
> you can throw such an exception without it being listed in the
> "throws" clause. This is how things like IllegalArgumentException and
> NullPointerException work.
>
> >
> > Klaus Bucka-Lassen
> >
> >
>
> Craig
>
>
