How much exception handling is to much?
-
I am working through an exsiting application and it has very few try catch blocks and is letting errors pass straight to the error web page. I make liberal use of try catch blocks am I overdoing it? How expensive is a try catch block am I missing something?
-
I am working through an exsiting application and it has very few try catch blocks and is letting errors pass straight to the error web page. I make liberal use of try catch blocks am I overdoing it? How expensive is a try catch block am I missing something?
The only reason for a catch block is to handle the exception by performing a task or adding additional information to the exception and rethrowin. Not just logging the exception and rethrowing, if exceptions are recorded, they should only be recorded once. Finally blocks/using statements should be used to clean up state like disposing of database connections. Most of the time exceptions should be so severe that the error web page, or a custom application level handler is the best way to handle them. One rule of thumb I use is that code in catch and finally blocks should be unimportant to the actual working of the application. If you have any logic in your application that requires the catch block for it to work correctly then the code is in the wrong place. As far as performance goes, for a typical asp.net application accessing a database, each request could throw and catch hundreds of exceptions and performance probably would not be affected because network access is so slow compared to processor time. So for most moderately well written applications most time is spent waiting for database response or sending and recieving data to the client. So, don't avoid catches because of performance issues. Use them to make your code easier to read and avoid them where it makes it more difficult.
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
-
The only reason for a catch block is to handle the exception by performing a task or adding additional information to the exception and rethrowin. Not just logging the exception and rethrowing, if exceptions are recorded, they should only be recorded once. Finally blocks/using statements should be used to clean up state like disposing of database connections. Most of the time exceptions should be so severe that the error web page, or a custom application level handler is the best way to handle them. One rule of thumb I use is that code in catch and finally blocks should be unimportant to the actual working of the application. If you have any logic in your application that requires the catch block for it to work correctly then the code is in the wrong place. As far as performance goes, for a typical asp.net application accessing a database, each request could throw and catch hundreds of exceptions and performance probably would not be affected because network access is so slow compared to processor time. So for most moderately well written applications most time is spent waiting for database response or sending and recieving data to the client. So, don't avoid catches because of performance issues. Use them to make your code easier to read and avoid them where it makes it more difficult.
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
andy brummer wrote: The only reason for a catch block is to handle the exception by performing a task or adding additional information to the exception and rethrowin. I would hope that's not your mantra. End users should never see exceptions. This is no better than showing them AV exceptions in native code, or even the dreaded blue screen of death. Exceptions are for whatever you need them for, whether that's recovering from an issue, ignoring certain known problems, logging, adding information and rethrowing, etc. This posting is provided "AS IS" with no warranties, and confers no rights. Software Design Engineer Developer Division Sustained Engineering Microsoft [My Articles] [My Blog]
-
andy brummer wrote: The only reason for a catch block is to handle the exception by performing a task or adding additional information to the exception and rethrowin. I would hope that's not your mantra. End users should never see exceptions. This is no better than showing them AV exceptions in native code, or even the dreaded blue screen of death. Exceptions are for whatever you need them for, whether that's recovering from an issue, ignoring certain known problems, logging, adding information and rethrowing, etc. This posting is provided "AS IS" with no warranties, and confers no rights. Software Design Engineer Developer Division Sustained Engineering Microsoft [My Articles] [My Blog]
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