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]
