Re: Error Handling Strategy
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? I've done exactly this way, I wrote my own ExceptionHandler and my own Exception(it's by now SisprevException:), and do everything there, for database errors(SQLException) I have a XML wich has every Oracle erros that can perhaps happen, then I test if this is a SQLException and call a method wich will handle my logic(read XML, identify the error and get the proper message), if its any other exception I handle diferently, of course I don't handle every kind of exception just those that I perhaps will get :) Like you said it really has benefits, I don't have anyone try and catch through my source, some times I have try and finally to release resources in case of an Exception. Dorilêo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Error Handling Strategy
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]
Re: Error Handling Strategy
Matthew Hughes wrote the following on 6/6/2005 12:21 PM: Can anyone tell me why this isn't a good idea? I've found it easiest to not have any try/catch logic in my Actions, and I just define the global exceptions I want to catch in my struts-config which forwards to an action that logs my error and then fowards to the appropriate page for displaying a nicer error page to the user. -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Error Handling Strategy
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]
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
Re: Error Handling Strategy
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]
Re: Error Handling Strategy
Validator Framework only validates against STATIC value, not dynamic ones. For example. a user input a deposit rate. the validator in web tier only validate whether it is a number or whether its value is positive and not excess 100( a static boundary). But the company's business rule also requires the rate value must not grater a certain value, which is dynamic. So the only way to validate this by accessing database. The DAO method check the value first. A business exception thrown if the value is invalid. Martin Gainty [EMAIL PROTECTED] wrote: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 To: Struts Users Mailing List 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 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] 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) __ Do You Yahoo!? Tired of spam
