On Wed, 20 Mar 2002, Matt Raible wrote:
> Date: Wed, 20 Mar 2002 20:27:39 -0700
> From: Matt Raible <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED]
> To: 'Struts Developers List' <[EMAIL PROTECTED]>
> Subject: RE: Declarative Exception Handling - Any Documentation?
>
> A little best-practices question...
>
> If I have the following 3 errors that can occur when uploading files in
> my UploadAction:
>
> errors.invalid.transcriptFile=The transcript file \"{0}\" doesn't appear
> to be a text file. Please convert it to a text file.
> errors.reading.file=An error occurred reading the file \"{0}\", please
> try uploading the file again.
> errors.file.exists=File \"{0}\" already exists in the asset repository.
> Select the \"Replace if Exists\" checkbox to overwrite.
>
> What is the best way to use Declarative Exception handling for these -
> should I have three different exceptions, or is it possible to have 1
> FileUploadException class that can render all 3 error messages?
>
I think this really depends on what you want to have happen next. If
you're going to go back to the input form again in all three cases, it's
probably just as easy to use a single exception handler for all three
scenarios -- if you want to take different actions, you can use different
ones.
Of course, you also have the choice of not throwing an exception at all --
you can do a forward directly from UploadAction to the appropriate place
as well. Using an exception lets you decouple the detection of a problem
with the decision of what to do next. If you already know (in
UploadAction) where you want to go next, it's probably just as easy to go
there directly.
> Sorry for all the questions - maybe I can help with documentation once I
> get this all figured out. Point me in the right direction to do this.
>
> Matt
>
Craig
> > -----Original Message-----
> > From: Matt Raible [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, March 20, 2002 8:21 PM
> > To: 'Struts Developers List'
> > Subject: RE: Declarative Exception Handling - Any Documentation?
> >
> >
> > After investigating the PasswordExpiredException, I'm a
> > little confused. This class uses the following code:
> >
> > <code>
> > public ExpiredPasswordException(String username) {
> > super("error.password.expired", username);
> > }
> > </code>
> >
> > But there is no key "error.password.expired" in
> > ApplicationResources.properties. In struts-config.xml there is
> >
> > <exception key="expired.password"
> > type="org.apache.struts.webapp.example.ExpiredPasswordExceptio
> > n" path="/changePassword.jsp"/>
> >
> > And I found an "expired.password" key, but this is never
> > used. How are each designed to be used - simply for logging?
> > There are no messages that show up in the log for either of these.
> >
> > Here's how I would expect these to be used.
> >
> > 1. If no key is specified in struts-config, then the key
> > "error.password.expired" would be used. 2. This message
> > would be attainable with the following JSP code:
> >
> > <%-- Error Messages --%>
> > <logic:messagesPresent>
> > <html:messages id="error">
> > <bean:write name="error"/><br/>
> > </html:messages>
> > </logic:messagesPresent>
> >
> > Is this correct? Also, is it possible to have a separate
> > .properties file for Exception messages?
> >
> > This stuff is great, as well as the rest of Struts - awesome
> > to work with this stuff. You all do an awesome job - makes
> > my life a lot easier.
> >
> > Matt
> >
> >
> > > -----Original Message-----
> > > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> > > Sent: Wednesday, March 20, 2002 5:55 PM
> > > To: Struts Developers List; [EMAIL PROTECTED]
> > > Subject: Re: Declarative Exception Handling - Any Documentation?
> > >
> > >
> > >
> > >
> > > On Wed, 20 Mar 2002, Matt Raible wrote:
> > >
> > > > Date: Wed, 20 Mar 2002 17:18:45 -0700
> > > > From: Matt Raible <[EMAIL PROTECTED]>
> > > > Reply-To: Struts Developers List <[EMAIL PROTECTED]>,
> > > > [EMAIL PROTECTED]
> > > > To: [EMAIL PROTECTED]
> > > > Subject: Declarative Exception Handling - Any Documentation?
> > > >
> > > > I *think* declarative exception handling has been added to the 1.1
> > > > beta 1 - correct me if I'm wrong. If so, where can I find good
> > > > documentation and examples on how to use it? This is all I found:
> > > >
> > > >
> > > http://www.mail-archive.com/struts->
> > > [EMAIL PROTECTED]/msg04150.htm
> > > > l
> > > >
> > >
> > > It has.
> > >
> > > To use it, you have to use the (new) execute() method in your
> > > Actions, instead of perform() -- the signature includes
> > > "throws Exception" so that you can throw any kind of
> > > exception you wish, and then have the controller catch it.
> > >
> > > To configure usage, use the <exception> elements inside a
> > > <global-exceptions> section for global definitions, or inside
> > > an <action> element for local overrides, analogous to the way
> > > forwards work.
> > >
> > > A contrived use of this is in the Struts example webapp -- if
> > > you enter the username "arithmetic", LogonAction will throw
> > > an ArithmeticException. Likewise, if you enter the username
> > > "expired" it will throw an ExpiredPasswordException (a
> > > business logic exception unique to this webapp). Only the
> > > business logic exception has a defined handler:
> > >
> > > <action path="/logon" ...>
> > > <exception key="expired.password"
> > >
> > > type="org.apache.struts.webapp.example.ExpiredPasswordException"
> > > path="/changePassword.jsp"/>
> > > </action>
> > >
> > > > Also, will Tiles be adapted as a Plug In?
> > > >
> > >
> > > Makes sense to me ... but I'm not going to have a chance to do it.
> > >
> > > > I upgraded my app using 1.1 beta 1 with Tiles & Validator this
> > > > afternoon
> > > > - took me about 10 minutes. Mostly validator changes. Nice work!
> > > >
> > >
> > > Cool!
> > >
> > > > Matt
> > > >
> > >
> > > Craig
> > >
> >
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
