I read that try, catch, finally way of exception handling
is very expensive. obviously, try-catch blocks is needed
to properly handle the exceptions. but how does finally
effect the performance, since code in this block will be
executed regardless of whether an exception is raised or
not.
More specifically, when using ADO.NET, would it be better
to do something like.
<code>
try {
using(IDataConnection conn) {
conn.Open();
// ... more code ...
}
}
catch (Exception e)
{
// ... handle exception ...
}
</code>
or is it better to do it like
<code>
try {
IDataConnection conn;
conn.Open();
// ... more code ...
}
catch (Exception e)
{
// ... handle exception ...
}
finally
{
if(conn.State != ConnectionState.Closed)
conn.Close(); // or conn.Dispose();
}
</code>
When exceptions aren't thrown, they're nearly free. When exceptions
*are* thrown, chances are you've got bigger things to worry about. In
short, unless you see a performance bottleneck which is *definitely*
related to exception handling, just code for elegance and readability.
<snip>
> More specifically, when using ADO.NET, would it be better
> to do something like.
<snip>
I'd go for the former - or more likely:
using (IDataConnection conn=...)
{
try
{
...
}
catch (Exception e)
{
...
}
}
as then you can still use conn to potentially give more information
when an exception is thrown.
I certainly wouldn't worry about the extra tiny overhead of effectively
having an extra try/finally due to the "using" construct.
--
Jon Skeet - <sk...@pobox.com>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too
Try/catch blocks are only expensive if an exception is actually
thrown/caught. If there are no exceptions, then I wouldn't worry about it.
That being said, do not depend on exceptions to control logic in your code.
Exceptions are just that, exceptions, and should be unexpected, if anything.
As for your code, I would use the first example, with the using
statement. It's easier to know that your resource is cleaned up.
Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- nicholas...@exisconsulting.com
"Daniel Jin" <shina...@yahoo.com> wrote in message
news:035901c2fdd8$f22a0ac0$3401...@phx.gbl...
It really depends upon what you're trying to do. The big difference
between:
try {...}
catch (Exception e) {...}
...
and
try {...}
catch (Exception e) {...}
finally {...}
is that the finally block is ALWAYS executed. The code after the try/catch
block is executed when program execution exits the try/catch block.
There's a subtle difference there. Suppose you have a return statement in
your try block. Code after the try/catch won't be executed, but code in
the finally block will. Also, from a code maintenance standpoint, a
finally block may make more sense. If you're doing something with a db
connection in your try block, and you create it there, and do whatever you
need to do there, it probably makes sense to close the connection in the
finally block, rather than outside. That way your entire database activity
is isolated in the try/catch/finally.
This isn't a complete explanation of try/catch/finally, but hopefully it
helps a bit.
--
Chris J. Breisch, MCSD.NET, MCDBA
Ignore my post. Somehow I completely missed the using statement.
thanks guys,
it sure helped. so I should put the try-catch inside of
using, not the other way around. ok, what would be the
best way to structure a connection and a datareader then?
Right now my code read like this.
// code declare connection ...
// code declare command ...
// code declare parameters ...
try {
using(conn) {
conn.Open();
using(IDataReader reader = cmd.ExecuteReader
(CB.CloseConn)) {
// ... read data out of reader
}
}
} catch {
// ... more code ...
}
as you can see, I really don't have a good sense of how to
properly structure my code. :) I look at that and it's
very messy. what's a better way of structuring it? help
appretiated.