Our experience as computer-users teaches us that Exceptions are big bad errors. After all, any time we see a modal dialog box with an "ok" and "Exception" in the title bar, it's an error. From a programmer's point of view there should be no equal sign between "Exception" and "Error". Exceptions are nothing but brilliant control structures that manage to span multiple call-stack-levels and include the ability to pass a message along the exception-handling chain. There's simply no other control structure that has that ability (ability to span multiple call-stack levels).
Considering that, why not use exception handling for validating an user-entered text field? Some times this just might be the best solution, especially if the code doing the validation is not directly under the button. Also, why not use exception handling for something that might go wrong 99% of the time? Why implement an alternative mechanism for passing around error codes when there's an readily available mechanism for doing that, complete with compiler support? Besides, trying to assess rather a certain condition is "anticipated in the normal course of operations" will be very subjective. It's better to judge exceptions by what they offer and what they cost. In my opinion, there are two cases where exceptions shouldn't be used: (a) When it makes code less readable. (b) When they affect performance. This is unlikely to happen. P.S: I'd like to see a case where the use of exception is detrimental to the program without braking my roule "A" (i.e: without making the program less readable) and without being in a looong loop. -- Cosmin Prund Doug Chamberlin wrote: > At 01:00 PM 2/3/2007, Cosmin Prund wrote: > >> The statement "And I do so without setting up unnecessary exception >> handling which is, I expect, much more expensive than several IS tests" >> makes it look like exception handling is something expensive and it >> should be avoided. It's not, and it should be used as often as possible. >> > > Yes, exception handling should be encouraged. However, sometimes developers > use exceptions to trap and process conditions that are expected to occur in > the normal course of operations and this should be avoided. So, you need to > be judicious. > > For example, when translating a user-entered string into a numeric value. > In those cases the developer can reasonably expect the user to enter a > non-numeric at some point. You might be tempted, therefore, to trap the > translation error with an exception and process the "error" that way. > > However, there have been considerable argument about whether this is > correct and proper use of the exception mechanism. Some would argue that > exception handling code should ONLY be used for conditions that cannot be > anticipated in the normal course of operations. The above example would NOT > qualify in this regard. > > Others would argue that exception handling should be used everywhere it > works, without regard for the frequency of the exception occurrences. They > think that even if a condition can normally occur 50% of the time it is OK > to use the exception mechanism to perform what is essentially an if-test in > the logic of the program. > > I agree with the former position and abhor the use of exception handling to > control normal logic flow in the program. > > _______________________________________________ > Delphi mailing list -> [email protected] > http://www.elists.org/mailman/listinfo/delphi > > _______________________________________________ Delphi mailing list -> [email protected] http://www.elists.org/mailman/listinfo/delphi
