Sorry, left out that part. Every event handler in a Forms application should have a catch, usually just to log and show a generic error message, hopefully more if there is better information to give the user. In ASP.Net a general error handler is usually sufficient. If you can do something better at the page level then add a handler there. Only after that should you add a catch handler to one of the events. Unfortunately I've seen
try
{
//do something
}
catch (Exception e)
{
throw e;
}
way too many times, and let the rant out in my answer. What I tried to get through with my answer was that exceptions are there to make your code easier to read and debug. What I was trying to get through is you should use it for the reasons you stated. However, detecting invalid input by catching an exception from int.Parse would probably be a bad way to structure your application when there is a cleaner way to validate user input. Typically the arguement against it is performance, which would be the case in something like a batch processing application. For an ASP.Net page that wouldn't really apply, because you are sending information over the network. So, for validating user input on an ASP.Net page I would either use the built-in validation controls or write custom validation code for all the input that would not throw exceptions under all input that I could test, and use a generic exception handler for cases that truely are exceptional and provide a relatively friendly error message to the user for that case. This was way too long of a reply considering we both have similar views on exception handling. I just come across as more of a jerk online. :sigh:
I can imagine the sinking feeling one would have after ordering my book, only to find a laughably ridiculous theory with demented logic once the book arrives - Mark McCutcheon
