> 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.
ahhh... the IIOP compatability thing... yes.... I might have to do some
spec reading here, but would it be a good guess at saying this restricution
doesn't apply to local interfaces? I'll go read up on it...
> 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.
yep, but its not..... a FinderException that is not an
ObjectNotFoundException is pretty useless to me - unless someone would
inform me how to do something useful with it, the best I can do is return a
"sorry ... something went wrong" message to the user....
> 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.
which is what I was trying to avoid (o:
thanks for the input, and the very valid point on 'remote exceptions'.
cheers
dim
>
> ----- 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".
>
===========================================================================
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".
