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]
