How expsensive in terms of performance is try / catch

[Michael Fenske]

Not including other arguments as to why not to proliferate code with
try / ctach blocks, is there a true performance hit in terms of
executing code with said try / catch blocks?

For example, is there stack trace back information (or other
diagnostic information) being tracked in the presence of try / catch
blocks that isn't being done without them?

I would think there is always a mechanism in place to accumulate stack
trace so that the framework itself can display any unhandled exception
data as the process melts down.

 

[Arne Vajhøj]

Not including other arguments as to why not to proliferate code with
try / ctach blocks, is there a true performance hit in terms of
executing code with said try / catch blocks?

For example, is there stack trace back information (or other
diagnostic information) being tracked in the presence of try / catch
blocks that isn't being done without them?

I would think there is always a mechanism in place to accumulate stack
trace so that the framework itself can display any unhandled exception
data as the process melts down.

If the exception does not happen: don't worry about performance.

If the exception happen as a result of user interaction: don't
worry about performance.

If the exception can happen millions/billions of times: do worry
about performance.

In the last case exception is probably not good design either -
something happening that often does not seem to be exceptional.

Arne

 

[Michael Fenske]

Not including other arguments as to why not to proliferate code with
try / ctach blocks, is there a true performance hit in terms of
executing code with said try / catch blocks?  [...]

Define "true".

It is correct that handling exceptions is slower than not handling
exceptions.  But as Arne says, this is only a noticeable problem in some
cases, and you shouldn't be using exceptions to control program flow anyway.

If you want to know if there's a real performance problem related to
exception handling, the only reliable way to do so is to measure
performance.  Make sure you do so with an optimized ("Release") build,
and _without_ a debugger attached (exception handling is _much_ slower
with the debugger attached).

But for the most part, you will find that if you design the code well
and don't rely on exceptions for controlling program flow, they won't
happen often enough for them to be a real performance issue.

Pete

Let me try to put it another way. I have been told that performance
will decrease just because there are try / catch blocks in code,
nevermind if they ever actually handle anything.

So a code block like:

try
{
int aa = 1;


DoThis();

DoThat();

DoSomethingElse();
}
catch (Exception ex)
{
}

will slow things down, consuming more memory to retain stack trace
information that the the code should be written as:


int aa = 1;

DoThis();

try
{

DoThat();

DoSomethingElse();
}
catch (Exception ex)
{
}

i.e. DoThis() doesn't throw exceptions (there are other reasons not to
include it in a try / catch block I realize and catching Exception not
good either but I'm ignoring those obvious faux pas for now).

Question is, from a performance, memory usage point of view, is there
harm in including all those statements inside the try/catch?

 

[Michael Fenske]

[...]
Question is, from a performance, memory usage point of view, is there
harm in including all those statements inside the try/catch?

Both of your examples have the same number of try/catch blocks.  So even
if each try/catch block reduced performance, both of those two examples
would perform the same.

More to the point, I will pick correct code over fast code any day.  If
the thing you are calling might throw an exception that you need to
handle, you need a try/catch block. Even if it slows your code down.

Note: try/catch blocks that simply eat exceptions are bad. Don't do
that, except possibly at the highest level of your program for the
purpose of error-reporting, and then only if you know for sure that an
exception cannot have destabilized your program (keeping in mind that
some exceptions, such as OutOfMemoryException, might be unrecoverable).

If you are designing the entire hierarchy of code and so have complete
control over how errors are handled, then you may still wonder whether
try/catch is better than returning error values.  But the only way to
answer that is to measure performance and see if it matters in your
scenario.

That said, intuitively it's likely to be a wash. One of the advantages
of exceptions is that error handling needs to be present only at the
site where the error can in fact be dealt with. It allows all the code
in between to not have to worry about it.

So, not only can the code itself be simpler, you also don't have to
chain return values that would otherwise be needed in order to propagate
errors back to the level where the error will actually be handled.
Checking, storing, and returning all those return codes can itself be
overhead.

 From a performance point of view, either approach is unlikely to have
any real effect on how fast your code runs. But if you're in a situation
where it matters, the only correct way to decide is to measure the
actual performance and see for yourself.

Probably one of the strongest arguments in favor of using exceptions is
that the entire .NET API is designed around them. You can avoid them in
your own code, but you can't avoid dealing with them altogether, and
your own code will seem out-of-place if it's not using exceptions for
error handling.

Pete

Thanks Pete. i'm going to assume from this statement:

Both of your examples have the same number of try/catch blocks. So even
if each try/catch block reduced performance, both of those two examples
would perform the same.

That it doesn't matter how much stuff is inside the try block its
really the number of try / catch block occurences that may have an
effect on performance. I think I have a fairly decent grasp on when
to use them I'm just trying to satisfy some curiosty on my part at
this point as to how performance is affected by them.

I also appreciate your thoughts on return codes vs. exceptions. I go
back to a time before exceptions were around and exclusively used
return code propagation to monitor the state of the call chain. I
would generally prefer them mostly because that is what I am used to
and comfortable with which IMHO is as equally an evil position as
someone relying solely on exceptions because that is the .NET way.

 

[James A. Fortune]

Probably one of the strongest arguments in favor of using exceptions is
that the entire .NET API is designed around them. You can avoid them in
your own code, but you can't avoid dealing with them altogether, and
your own code will seem out-of-place if it's not using exceptions for
error handling.

I'm impressed by .NET's extensive use of exceptions - negatively! I
certainly agree that exceptions should not be used for flow control.
I also agree that they must be used, but I try to minimize or
compartmentalize their use, even eliminate the need for them where
possible.

From "More Effective C#" (Bill Wagner), p. 147:

[Providing test conditions increases robustness]
Exceptions are costly at runtime, and writing exception-proof code is
difficult. If you don't provide APIs for developers to test
conditions without writing many try/catch blocks, you aren't providing
a robust library.

[Exceptions vs. return codes]
Exceptions are the preferred failure-reporting mechanism because they
have many advantages over return codes as an error-reporting
mechanism. Return codes are part of a method's signature, and they
often convey information other than error reporting. Whereas return
codes are often the result of a computation, exceptions have one
purpose only: to report failures. Because exceptions are class types
and you can derive your own exception types, you can use exceptions to
convey rich information about the failure.

Unless the pros and cons have actually gone through the brain, using a
wider exception in place of a test and an exception is a bad habit -
one that seems all too prevalent. By "test" I mean something like
checking for the existence of a file before trying to open it. In
summary, the fact that the .NET API uses a lot of exceptions is, to
me, a weak argument for using them extensively, but perhaps the .NET
designers actually thought about all the pros and cons first .

James A. Fortune
(e-mail address removed)

 

[Michael Fenske]

Thanks Pete.  i'm going to assume from this statement:

That it doesn't matter how much stuff is inside the try block its
really the number of try / catch block occurences that may have an
effect on performance.

That's correct.

[...]  I
would generally prefer them mostly because that is what I am used to
and comfortable with which IMHO is as equally an evil position as
someone relying solely on exceptions because that is the .NET way.

I would argue it's a "more evil position" (inasmuch as it's "evil" at
all…that's a pretty strong word ), because while "that is the .NET
way" doesn't provide any specific technological justification, there is
at least some known benefit to follow existing paradigms simply for the
sake of consistency.

Pete

True enough, I can buy into the consistency argument. As for the
"evilness" of it all, I now remove tongue from cheek.