typically, how expensive is try catch?

Discussion in 'C++' started by Nick Keighley, Mar 22, 2007.

  1. 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
     
    Nick Keighley, Mar 22, 2007
    #1
    1. Advertising

  2. Nick Keighley

    red floyd Guest

    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.
     
    red floyd, Mar 22, 2007
    #2
    1. Advertising

  3. On Mar 22, 10:07 am, "Nick Keighley"
    <> 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.
     
    Jeremy Noring, Mar 22, 2007
    #3
  4. Nick Keighley

    Noah Roberts Guest

    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.
     
    Noah Roberts, Mar 22, 2007
    #4
  5. 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/]______\/
     
    Adrian Hawryluk, Mar 22, 2007
    #5
  6. Nick Keighley

    Ian Collins Guest

    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.
     
    Ian Collins, Mar 22, 2007
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. bienwell
    Replies:
    4
    Views:
    3,898
    bienwell
    May 27, 2005
  2. Replies:
    0
    Views:
    376
  3. John Dalberg

    Least expensive server pdf control?

    John Dalberg, Sep 15, 2005, in forum: ASP .Net
    Replies:
    0
    Views:
    395
    John Dalberg
    Sep 15, 2005
  4. Mickey Segal
    Replies:
    3
    Views:
    2,331
    Mickey Segal
    Jul 10, 2003
  5. Aaron J. Margosis
    Replies:
    7
    Views:
    768
    Richard Maher
    Feb 12, 2008
Loading...

Share This Page