Firstly I am also merely a struggler within this minefield of new stuff trying to work out what to do. I would approach such validation differently from my reading of material on this subject, which I find REALLY hard to interpret any definitive path from.
FWIW I would avoid throwing exceptions for data difficulties I am EXPECTING. Thus if you need to avoid duplicates I would tend to not treat a dupe as an exception but would test for it. If a vital attribute was missing that too would be a badly formed thing. Thus I would report from a test of each condition to, as Jon says, some central error object like (or try to): 'Saving your new user failed because: * No dupes..... * Missing thing.... * Etc Please re-enter......' This is because exceptions are regarded as expensive from what I can see and this type of cumulative message is fairly legible and fits the bill. I guess that is pretty much your second pattern. Can take a minute to implement at first but once you have a framework arranged it can be OK. An exception, for me, would be (for instance) if data entered violated referential integrity in a way I had not predicted. Cheers, Iain -----Original Message----- From: Jon Finley [mailto:[EMAIL PROTECTED]] Sent: 30 August 2002 13:44 To: dotnet Subject: RE: How would you handle an error - design pattern question?? 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.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/ Disclaimer This message may contain information which is legally privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any unauthorised disclosure, copying, distribution or use of this information is strictly prohibited. Such notification not withstanding, any comments or opinions expressed are those of the originator, not of Taylor Made Computer Solutions, unless otherwise explicitly stated. --- 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/
