Menu
I just finished reading this article on the advantages and disadvantages of exceptions and I agree with the sentiment that Try-Catch blocks should not be used for "normal" control-flow management (don't use them like a goto). However, one author made (good) points about Maintainability and especially Performance that made me wonder about the same thing in Try-Finally blocks.
I surround every Connection open event in my ASP.NET application with a Try so that I can be sure to close the Connection in a Finally. Leaking connections is obviously NOT a good thing in a web app and I doubt I'd change this practice but what are your thoughts?
Note: I do have connections wrapped in a DAL and could close connections when the object destructor is called but this seems sketchy to me. As far as I know, you cannot count on a destructor being called in the event of an exception. Am I wrong?
575
The try statement defines the code block to run (to try). The catch statement defines a code block to handle any error. The finally statement defines a code block to run regardless of the result. The throw statement defines a custom error.
In the try-catch , the finally block is used to execute a code block whether or not an error occurs. It can be used to continue the flow of the application after an error occurs when placed in the catch block.
A Finally block is useful for running any code that must execute even if there is an exception. Control is passed to the Finally block regardless of how the Try...Catch block exits. The code in a Finally block runs even if your code encounters a Return statement in a Try or Catch block.
If you've one if/else block instead of one try/catch block, and if an exceptions throws in the try/catch block, then the if/else block is faster (if/else block: around 0.0012 milliseconds, try/catch block: around 0.6664 milliseconds). If no exception is thrown with a try/catch block, then a try/catch block is faster.
You don't need to avoid the try {} ... finally {} pattern of coding. But as far as your connections go, since they're IDisposable, use "using" instead, since it does the same thing for you as the longer and more cumbersome try/finally block.
118
The bad thing about using try-catch block everywhere is that in consuming the exception you potentially conceal bad code. Try-finally (without the catch) does not hide exceptions, but does provide code execution guarantees. In your case, you can expect certain types of exceptions even from well formed SQL commands (like trying to insert a duplicate row) and thus I think the use of finally is well-justified. This assumes that you feel, as I do, that the connections should be short-lived and opened/closed when used and not for the life of your DAL.
EDIT: I would second @Dave Markle's recommendation. A using block is much more elegant and semantically equivalent. The only time I might favor a try-finally over using is to avoid multiple, nested usings in favor a single try-finally.
21
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
