Your response is typical of those who argue that the exception handling mechanism, because it is so comprehensive and elegant, should be used for handling a wide variety of conditions that might reasonably be anticipated by the developer. Those include data validation of user input, for example.
The alternative position is that the exception handling mechanism was invented for handling ONLY unexpected conditions comprehensively without cluttering up the code. If you fully expect that in some cases the user will enter invalid data, to continue to use that example, you should write a data validation function and call it, reserving the exception handling mechanism for anything that goes wrong that you failed to anticipate. An analogy: Guns are manufactured with a mechanism, often called a "safety", to prevent the trigger from firing the gun. However, only fools rely on the safety to prevent accidentally shooting their friends. Proper gun safety calls for handling the gun carefully all the time. "Always treat it as though it was loaded." The safety should be relied upon to catch any mistakes you might make IN SPITE OF properly handling the gun. Admittedly, there is a big difference between software and guns, but I hope you get the point. It is not that you can't do what you advocate. It is that it is not the best way to structure software. Now, I'm sure I will fail to convince you of the alternative view with just this brief message. However, I originally posted in order to ensure that readers don't blindly go off using the exception handling mechanism without first thinking fully about what they were doing. I suggest we leave it at that. _______________________________________________ Delphi mailing list -> [email protected] http://www.elists.org/mailman/listinfo/delphi
