Alireza, I haven't tried this, but it seems like if you created a base database exception class that had the ability to parse the SQLException messages and return the appropriate application level exception, it might address your needs.
robert > -----Original Message----- > From: Alireza Fattahi [mailto:[EMAIL PROTECTED]] > Sent: Thursday, January 09, 2003 6:11 AM > To: 'Struts Users Mailing List' > Subject: Error Handling Database constraints > > > Hi, > > As we know there are two types of errors. > > 1) The user input error, for example and email without @. Well this can be > handled easily and *separately from code* by commons validation frame work > > 2) The errors that violate the database consistency. For example > in the user > table the user_name filed must be unique. The thing we do is: > first we add a > constraint to database for user_name. Then when an insert > requests first we > select user_name from database to see if there is any duplicate. Well it > means that we handle the constraint checking task our selves with > java code. > Why do we do this? Why did we just let the insert happens and work with > SQLException? Because the returned error from database can not be > handled or > modified nicely. These errors are changed for each database. > > Are we doing the right way? Is there any better way available for error > handling Database Constraints? > > > Alireza. > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
