> If MyCustomException extends RuntimeException the container will rollback
> the transaction. If it's an application exception it's the responsibility
> of the Bean Provider to setRollbackOnly() or not.
yep, and how often do you throw an exception and not roll back the tx? This
to me is another benefit of this approach, as I haven't yet (and this may
just be something that I'll do in time to come, and haven't come across yet)
ever caught a CreateException (DuplicateKey excused), FinderException
(ObjectNotFound excused), or other EJB exception classes.
I suppose I should point out that I dont see this being an everything
approach. In places where I catch an ObjectNotFoundException and deal with
it, nothing would change. This is only where I have some method that
wouldn't otherwise need to declare an exception if it weren't for the EJB
exceptions....
> We tend to do (b) for what we consider system exceptions, bugs or
> unexpected conditions (NamingException, RemoteException, SQLException,
some
> FinderExceptions, ...).
excellent (o: thats what I like to hear....
> In a few cases, where the exception can be expected under normal
> conditions, we're doing (a).
yep.... I'm sure those cases will always exist.
thanks for the feedback.
cheers
dim
>
> ----
> Peter
>
>
>
>
>
> Dmitri Colebatch <[EMAIL PROTECTED]>@JAVA.SUN.COM> on 21/03/2002 07:48:06
>
> Please respond to Dmitri Colebatch <[EMAIL PROTECTED]>
>
> Sent by: A mailing list for Enterprise JavaBeans development
> <[EMAIL PROTECTED]>
>
>
> To: [EMAIL PROTECTED]
> cc:
>
> 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".
