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.

We tend to do (b) for what we consider system exceptions, bugs or
unexpected conditions (NamingException, RemoteException, SQLException, some
FinderExceptions, ...).
In a few cases, where the exception can be expected under normal
conditions, we're doing (a).

----
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".

Reply via email to