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
