Ahh, failed to read your original message correctly. I didn't realize you
were talking about Create/Finder etc exception. I'll agree, they're a
serious nuisance, and should really be unchecked. All our code just catches
them and wraps them in an unchecked exception.
Checked exceptions in general are dubious value. I vascilate from day to
day on the value of them. We write an API, and use checked exceptions for
pretty much everything. It's a source of many complaints from our
customers. I'm seriously considering switching to using unchecked
exceptions for the most part, when we do a new version of the API.
----- Original Message -----
From: "Dmitri Colebatch" <[EMAIL PROTECTED]>
To: "J Mark Birenbaum" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Friday, March 22, 2002 2:07 PM
Subject: Re: what to do with exceptions
> > 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".
