You are quite right Tore. Whatever the design your point would need consideration.
I guess it is not unfeasible to handle multiple exceptions OR consider the change between check and commit to be an unexpected exception in a lower volume app. But to a large extent your point does refute the value of an extra coded check. Cheers, Iain -----Original Message----- From: Bostrup, Tore [mailto:[EMAIL PROTECTED]] Sent: 30 August 2002 14:59 To: dotnet Subject: RE: How would you handle an error - design pattern question?? Just a word of caution - especially important for high volume/high activity implementations: Checking ahead of time is not completely safe, because conditions may change between your check and your actual operation. Therefore, you are better off just intercepting the exception, since you'll have to handle it anyway. HTH, Tore. -----Original Message----- From: Iain Smallwood [mailto:[EMAIL PROTECTED]] Sent: Friday, August 30, 2002 9:12 AM To: dotnet Subject: RE: How would you handle an error - design pattern question?? 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.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/
