This is a good question Rick, I am wondering what others are doing as well. I should prefact the following with the fact that I am NOT an expert on this stuff (just trying to learn).
Currently I use: 1) Client-side javascript to do basic data validation. 2) Lots of validation code in business object layer that sets a public "ErrorText" property. If this property is anything but blank/nothing after the method call (i.e. save/delete) then an error occurred. I then display the value of this property on a (usually invisible) "Error" label. 3) If SQL (or whatever data source) returns on error to the business object I set the business "ErrorText" property and do the same thing as #2. I'm not sure whether this is the "best" solution or not. Getting a useful/friendly error message seems to be the hardest part of my process. I should add that the "ErrorText" property is set whenever an exception is thrown (so both exception errors and business logic errors are handled the same way). I started using the validators but ran into problems with javascript so have abandoned them. Curious about others experiences. Jon > -----Original Message----- > From: Rick Casey [mailto:[EMAIL PROTECTED]] > Sent: Thursday, August 29, 2002 5:17 PM > To: dotnet > Subject: How would you handle an error - design pattern question?? > > > I'm moving from ASP to ASP.NET and I am using C# to write the > objects that the web forms will interact. > > I want to know how do most of you test your data before > submitting it to the database? > > For example, say that username in the user object is modified > but the new username is already in the database. How would > you notify the web form from the user object that the > username is already used? > > Couple possibilities... > > ** > Should I use a "IsUserDataValid()" function that would throw > an exception for each error that the user can have? > > This would be ok, but it seems that I would need to have many > roundtrips to fix the many possible errors that could be > found because only one exception would be thrown per roundtrip. > ** > Or would the better idea be to have a validation function for > each user attribute and call each of those and using the > try/catch to find the exceptions? > > This would be fine, but it requires the developer to call > many functions to test the input before they could call the > user.saveProperties() function. What if they forget one? > ** > > I am leaning towards the second idea myself because the > developer must know what attributes they are saving anyways, > and it can find all the errors in one trip and throw an > exception for each of them. > > I just want to state that I do not want to use the input > field validators. > > Thanks for sharing your experience... > > Rick. > > > --- > You are currently subscribed to dotnet as: > [EMAIL PROTECTED] To unsubscribe send a blank email to > %%email.unsub%% > > --------- > Administrated by 15 Seconds : http://www.15Seconds.com > List Archives/Search : http://local.15Seconds.com/search > Subscription Information : http://www.15seconds.com/listserv.htm > Advertising Information: http://www.internet.com/mediakit/ > > > --- You are currently subscribed to dotnet as: [email protected] To unsubscribe send a blank email to [EMAIL PROTECTED] --------- Administrated by 15 Seconds : http://www.15Seconds.com List Archives/Search : http://local.15Seconds.com/search Subscription Information : http://www.15seconds.com/listserv.htm Advertising Information: http://www.internet.com/mediakit/
