> -----Original Message----- > From: Hubert Rabago [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 08, 2004 6:39 AM > To: Struts Users Mailing List > Subject: Re: Proper place for validation > > > Maybe there weren't a lot of comments because people agreed > with Robert. :) > > For your followup, the reason you get one of (a) and (b) is because > you're thinking that the error message should come from the business > tier. I like to think that it shouldn't.
In fact, not only shouldn't it just come from the business tier, it can't. What happens if your DBA accidently fat fingers your DB (drop table or db, deletes a column, marks it read only)? or your SQL? What happens if your cleaning lady/cow-orker/boss kicks the network cable out of the DB? Or the network cable goes bad? Where do these kinds of things get handled?[1] Which is why I like chained exceptions. The DAO layer has an issue, that's a specific message that the business layer wraps up in an exception that get tossed up to presentation, where the struts exception handler decides what to dispaly, and how to dispaly it. >Error messages are a > presentation tier responsibility. In the business tier, the exception > should be able to communicate with other objects what the error was. > The way I do this is with specific exception types or with error > codes. If the exception is caught by another business tier object, it > can check the error code to see what exactly happened. If it bubbles > up all the way to the presentation tier, it can do the same, and then > select an i18n error message to show, or other take other action as > needed. I agree... handle the right exception at the right time, but never ignore. [1] Yes these have all happened in production with highly competent people. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
