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? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
