Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > typically, how expensive is try catch?

Reply
Thread Tools

typically, how expensive is try catch?

 
 
Nick Keighley
Guest
Posts: n/a
 
      03-22-2007
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?


--
Nick Keighley

 
Reply With Quote
 
 
 
 
red floyd
Guest
Posts: n/a
 
      03-22-2007
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.

>
> 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.
 
Reply With Quote
 
 
 
 
Jeremy Noring
Guest
Posts: n/a
 
      03-22-2007
On Mar 22, 10:07 am, "Nick Keighley"
<(E-Mail Removed)> wrote:
> 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.

 
Reply With Quote
 
Noah Roberts
Guest
Posts: n/a
 
      03-22-2007
red floyd wrote:
> 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.
>
>>
>> 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.


And if you don't know then it doesn't matter.
>
>
>> 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.


Exactly.
 
Reply With Quote
 
Adrian Hawryluk
Guest
Posts: n/a
 
      03-22-2007
Noah Roberts wrote:
> red floyd wrote:
>> 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?


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/]______\/
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      03-22-2007
Adrian Hawryluk wrote:
> Noah Roberts wrote:
>
>> red floyd wrote:
>>
>>> 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.

--
Ian Collins.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: How include a large array? Edward A. Falk C Programming 1 04-04-2013 08:07 PM
converting a nested try/except statement into try/except/else John Salerno Python 20 08-11-2006 02:48 PM
Can I have a second TRY inside the first TRY/CATCH in ASP.NET ??? bienwell ASP .Net 4 05-27-2005 05:05 PM
Compiler error occurred when try to use a flexible template expression in preprocessor definesCompiler error occurred when try to use a flexible template expression in preprocessor defines snnn C++ 6 03-14-2005 04:09 PM
Try, Try, Try, again... Rick12N4@netscape.net Computer Support 3 01-29-2005 04:02 PM



Advertisments