typically, how expensive is try catch?

[Nick Keighley]

Hi,

I know in principal this is unanswerable as it is be implementation
dependent.I have a code base that is heavily littered with try/catch
clauses (the CASE tool has been set up to put a try/catch round
every member function).

[what's that screaming sound I can here?]

Now I know this is BAD but I just wondered how bad. Will it kill
performance? Eat memory? I don't expect many exceptions to
be thrown.

Or do I need to strip the try/catches out and profile it?

 

[red floyd]

Hi,

I know in principal this is unanswerable as it is be implementation
dependent.I have a code base that is heavily littered with try/catch
clauses (the CASE tool has been set up to put a try/catch round
every member function).

[what's that screaming sound I can here?]

This is bad, not because of performance issues, but because of design
issues. The whole point of exception handling is to deal with
exceptional conditions at the "right" level. Otherwise, most of catch
blocks will simply re-throw the exception. By catching at every
function, you might as well just propagate a return code.

Now I know this is BAD but I just wondered how bad. Will it kill
performance?

Possibly, ideally, if you don't throw, it's mminimal.

Eat memory?

other than unnecessary code, no.

Or do I need to strip the try/catches out and profile it?

As always, benchmarking profiling is your best answer to performance
related questions.

 

[Jeremy Noring]

Now I know this is BAD but I just wondered how bad. Will it kill
performance? Eat memory? I don't expect many exceptions to
be thrown.

Or do I need to strip the try/catches out and profile it?

If you want to know "how bad," you'd have to profile the code with and
without the try/catch statements, although IMO using try/catch
excessively is more of a design foul than a performance foul.

A few questions to ask yourself:

1. Does it matter? If the program runs "fast enough," do you need to
remove the try/catch statements?
2. If it does matter, how much CPU is the try/catch actually using
relative to other parts of the application? If it's .1% (note: this
is me pulling some number out of my arse) of your total CPU time, I'd
wager there's something else that's more worthy of attention.

 

[Noah Roberts]

Hi,

I know in principal this is unanswerable as it is be implementation
dependent.I have a code base that is heavily littered with try/catch
clauses (the CASE tool has been set up to put a try/catch round
every member function).

[what's that screaming sound I can here?]

This is bad, not because of performance issues, but because of design
issues. The whole point of exception handling is to deal with
exceptional conditions at the "right" level. Otherwise, most of catch
blocks will simply re-throw the exception. By catching at every
function, you might as well just propagate a return code.

Probably a throwback from Java where you absolutely have to catch or
declare as throwable any and all exceptions that might be thrown beneath
you. It's such a pain in the ass that it wouldn't surprise me at all if
a RAD tool decided to just wrap all functions with try/catch to avoid
the hassle.

Possibly, ideally, if you don't throw, it's mminimal.

And if you don't know then it doesn't matter.

As always, benchmarking profiling is your best answer to performance
related questions.

Exactly.

 

[Adrian Hawryluk]

Hi,

I know in principal this is unanswerable as it is be implementation
dependent.I have a code base that is heavily littered with try/catch
clauses (the CASE tool has been set up to put a try/catch round
every member function).

[what's that screaming sound I can here?]

This is bad, not because of performance issues, but because of design
issues. The whole point of exception handling is to deal with
exceptional conditions at the "right" level. Otherwise, most of catch
blocks will simply re-throw the exception. By catching at every
function, you might as well just propagate a return code.

Probably a throwback from Java where you absolutely have to catch or
declare as throwable any and all exceptions that might be thrown beneath
you. It's such a pain in the ass that it wouldn't surprise me at all if
a RAD tool decided to just wrap all functions with try/catch to avoid
the hassle.

I don't understand what the big deal of declaring what the function can
throw. Without knowing what can be thrown, you can't expect to catch
the exception and do something meaningful with it, can you?


Adrian
--
_____________________________________________________________________
\/Adrian_Hawryluk BSc. - Specialties: UML, OOPD, Real-Time Systems\/
\ _---_ Q. What are you doing here? _---_ /
\ / | A. Just surf'n the net, teaching and | \ /
\__/___\___ learning, learning and teaching. You?_____/___\__/
\/______[blog:__http://adrians-musings.blogspot.com/]______\/

 

[Ian Collins]

Nick Keighley wrote:

Hi,

I know in principal this is unanswerable as it is be implementation
dependent.I have a code base that is heavily littered with try/catch
clauses (the CASE tool has been set up to put a try/catch round
every member function).

[what's that screaming sound I can here?]


This is bad, not because of performance issues, but because of design
issues. The whole point of exception handling is to deal with
exceptional conditions at the "right" level. Otherwise, most of
catch blocks will simply re-throw the exception. By catching at
every function, you might as well just propagate a return code.

Probably a throwback from Java where you absolutely have to catch or
declare as throwable any and all exceptions that might be thrown
beneath you. It's such a pain in the ass that it wouldn't surprise me
at all if a RAD tool decided to just wrap all functions with try/catch
to avoid the hassle.

I don't understand what the big deal of declaring what the function can
throw. Without knowing what can be thrown, you can't expect to catch
the exception and do something meaningful with it, can you?

That's the point, an intermediate function may not care what a function
it calls throws. The clean up is done higher up the call stack.