Huang-
I am a bit confused by statement 'by accessing database'
Could you explain why am error message must be done 'by accessing database'
instead of by properties or ResourceBundles?
Thanks,
Martin-
----- Original Message -----
From: "Xinsheng [mike] Huang" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <user@struts.apache.org>
Sent: Monday, June 06, 2005 3:59 PM
Subject: Re: Error Handling Strategy
Rule 1: let the global exception handler handle the
unwanted-exceptions,usually they are system exceptions.
Rule 2: for business exceptions that your action catchs and put an action
error/message in request so that the jsp displays a message to user to
recovery. A business exception is required only the validation can't be
done in Validator Framework, and it is must be done by accessing database.
"Frank W. Zammetti" <[EMAIL PROTECTED]> wrote:
I've gotten into the habit of using the Struts global exception handling
mechanism... Anything that can be handled in my code I catch and handle
(i.e., retrying a connection to a back-end system perhaps), anything else
I let bubble up and handle it in the global handler.
This to me is pretty much ideal as-is, I don't see much benefit in doing
anything else. This keeps me from having to write all sorts of exception
handling all over the place, except where it's truly needed/wanted. Could
this maybe help you as well?
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
On Mon, June 6, 2005 12:21 pm, Matthew Hughes said:
I really do not like the way my current application handles errors as
every error requires three or four lines and it is very redundant.
I have been reading a lot about Exception(s) and how developers are
slowly seeing the benefits of extending their Exception(s) from
RuntimeException freeing coders from writing catch blocks when they
can't do anything about it or just throwing it up again adding "throws
SQLException" to every method up the line.
With the exception (no pun intended) of using ActionErrors in
ActionForm.validate(), could anyone tell me why it wouldn't be much
better to use Exceptions to handle errors.
Say I have three layers in my application: model, business,
controller/view. If the model error throws an Exception and not a
RuntimeException, both the business and the controller/view layers
have to catch it or pass it on. With RuntimeExceptions you have the
best of both worlds: you don't have to do ANYTHING if you don't know
what to do with it, or if you do know what to do with it, you can
catch it.
In my new application design I am employeeing this strategy and using
custom ExceptionHandler classes to catch, log, and redirect the user
to the appropriate pages. In my Exception classes, instead of a
non-localized string as the exception message, I use a message key
which I can then retrieve and translate into a localized string for
the end user. This has two main benefits: you are forced to actually
THINK about your error messages as you need to look them up in a
properties file and they can be organized somewhat categorically AND
you don't have to write two different error messages for both the
developer and the end user. If the developer wants more information,
he can look at the error log for the stack trace. Can anyone tell me
why this isn't a good idea?
---------------------------------------------------------------------
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]
Xinsheng [Mike] Huang
SCJP -- Sun Certified Programmer for Java 2 Platform
SCJD -- Sun Certified Developer for Java 2 Platform
SCEA -- Sun Certified Enterprise Architect for J2EE
410-790-7462(C)
---------------------------------
Yahoo! Mail
Stay connected, organized, and protected. Take the tour
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
