One problem with throwing runtimes from a session bean, is that the EJB spec
says that runtimes will not be returned to the client, but instead, a
RemoteException will occur. In Weblogic, you can then get the original
RuntimeException out of the the RemoteException, but that behaviour varies
across EJB servers.
Basically, if it's a "Business Logic" exception, it should not be runtime.
For any error/failure condition that you want to provide useful information
to the user, you need to throw it as a checked exception.
That said, internally to your beans, you could throw things as Runtimes, and
just wrap every method in something that catches the runtimes, and wraps
them in a generic checked exception, and then unwrap it immediately on the
client side.
----- Original Message -----
From: "Dmitri Colebatch" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, March 20, 2002 11:48 PM
Subject: Re: what to do with exceptions
> > We throw a CustomException and catch it in the webtier.This
> > is then forwarded to a Error jsp page which takes the
> > error message(user friendly) and the possible
> > reasons(From Property File for each type of Exception) and
> > displays it on the page.
>
> yep... thats what we do atm... but tell me, do you achieve anything that
you couldn't achieve by the use of custom error pages?
>
> If all you're doing is (struts code)
>
> catch (MyCustomException e)
> {
> // forward to web page
> return mapping.findForward("error-page");
> }
>
> then if MyCustomException was runtime, you could achieve the same thing by
using the exception pages....
>
> I'm just thinking there's an opportunity to simplify things...
>
> cheers
> dim
>
> >
> >
> > Chandra
> >
> > -----Original Message-----
> > From: A mailing list for Enterprise JavaBeans development
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Dmitri Colebatch
> > Sent: Thursday, March 21, 2002 11:58 AM
> > To: [EMAIL PROTECTED]
> > Subject: what to do with exceptions
> >
> >
> > hey everyone,
> >
> > something thats been in the back of my head for a while.
> >
> > what do ppl do with the various exceptions thrown in EJB? Specifically,
in
> > the web tier. typical scenario, some code in the web
> > tier needs to create a SLSB, and invoke a method on it. In the SLSB,
the
> > invoking of that method has to deal with another 3-4 EJB
> > exceptions. So, do you
> >
> > a) catch them, and rethrow them as your own custom exception type
> > b) catch them, and rethrow them as a runtime exception
> > c) just add them to the throws clause
> >
> > and then in the web tier, do you handle these exceptions each
individually,
> > or do you just let the 500 error page pick them up
> > (assuming you have a nice one).
> >
> > I'm always inclined to do (b), as the only time I ever see them is in
> > development when I've made an error... its unlikely I'm going
> > to be able to deal with them gracefully anyway, so it seems logical -
> > however, at the same time I've got the voice in the back of my
> > head telling me I'm being lazy...
> >
> > be interested to hear other ppl's thoughts on this.
> >
> > cheers
> > dim
> >
> >
===========================================================================
> > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
> > of the message "signoff EJB-INTEREST". For general help, send email to
> > [EMAIL PROTECTED] and include in the body of the message "help".
> >
>
>
===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
