Right now I just throw it.. do I need to put in a request?
-----Original Message-----
From: Carlos Sánchez [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 02, 2003 3:50 AM
To: 'Struts Users Mailing List'
Subject: RE: Exception framework Usage
Have you tried to put the exception (under "exception") in the request
and
use
<c:out value='${exception.message}'/>
> -----Mensaje original-----
> De: Mohd Amin Mohd Din [mailto:[EMAIL PROTECTED]
> Enviado el: lunes, 01 de septiembre de 2003 20:47
> Para: 'Struts Users Mailing List'
> Asunto: RE: Exception framework Usage
>
>
> They way I'm doing at the moment is throwing an
> ApplicationException for any application centric ( business
> and view layer ) exceptions. The message of
> ApplicationException will tell exactly what happens.
>
> However, I'm trying to get the error message for a particular
> exception. Normally in Java it would be done
> 'e.getMessage()'. How can this be done in JSP using taglibs
> or scriptlets?
>
> Amin
>
> -----Original Message-----
> From: Navjot Singh [mailto:[EMAIL PROTECTED]
> Sent: Monday, September 01, 2003 8:53 PM
> To: Struts Users Mailing List
> Subject: RE: Exception framework Usage
>
> hi viral,
>
> You are thinking in the right direction. That's the way i do it.
>
> I have got 2 base exception classes. AppException and
> AppRuntimeException.
>
> 1. The exceptions that come under the purview of the business
> logic and these can be handled somehow at the
> controller/model layer to alter the flow of control MUST
> extend AppException.
>
> 2. The exceptions that does not come under the purview of the
> business logic and raise because of the system or network
> problems MUST extend AppRuntimeException.
>
> However, one must use some common sense to decide which
> exception should go where. Say, we are connecting to some URL
> and it may throw TimeoutException. which is not a checked
> exception. We must be ready to capture this and throw some
> checked exception. The caller may catch the exception and try
> connecting again....may be thrice
> ;-) and if still no luck the caller passes on the message to
> PRESENTATION.
>
> So your code will not be cluttered with "throws
> XRuntimeException" and tthese exceptions MUST be handled back
> at CONTROLLER layer only. MODEL layer should just handle
> CHECKED exceptions.
>
> Examples
> At Controller => DuplicateEmailException extends
> AppException (we may display the same form showing error on
> top) At Model => InsufficientBalanceException extends
> AppException (we may charge as much as he has got and rest of
> the amount we will accomodtae in next
> invoice)
>
> DatabaseAccessException extends AppRuntimeException ( as
> there is hardly anything we can do about this. We MAY show
> some nice "SORRY" page and/or may LOG this exception somewhere)
>
> BTW, there is some nice article on "Exception handling" on
> IBM Developer site. Do check.
>
> hope this helps and suggestions are welcome.
> Navjot Singh
>
>
> -----Original Message-----
> From: Viral_Thakkar [mailto:[EMAIL PROTECTED]
> Sent: Monday, September 01, 2003 5:50 PM
> To: Struts Users Mailing List
> Subject: Exception framework Usage
>
>
> Hi,
>
>
>
> Please suggest the exception framework in a scenario in a
> following scenario.
>
>
>
> Struts Action class a Business Delegate --> EJB a OR Mapping (Top
> link) a
> Domain classes
>
>
>
> Please validate the below lines.
>
>
>
> There will be three layers at which we need to handle the exception.
>
>
>
> At EJB layer, at business delegate and at struts layer.
>
>
>
> 1.. EJB layer (session bean) methods will throw the
> (Application) business exceptions along with RemoteException.
> In the catch block it will throw the EJBException (in case of
> checked system exceptions like NamingException).
> 2.. At business delegate layer, we will throw the
> application exceptions in the catch block rather than
> EJBException to decouple the web layer and EJB layer.
> 3.. At struts layer, in the Action class's execute(), we
> will catch all these business exceptions.
>
>
> Please provide your valuable inputs.
>
>
>
> Thanks in advance.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
