Re: Real life cost of using exceptions for control flow?

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: Bruno Jouhier [MVP] (bjouhier_at_club-internet.fr)
Date: 06/11/04 

Date: Fri, 11 Jun 2004 19:52:35 +0200

"Miyra" <miyra70@yahoo.com> a écrit dans le message de
news:a07d6578.0406101437.439fb7d8@posting.google.com...
> Hi. I'm working with an app that uses exceptions for control flow.
> These are code blocks where exceptions are thrown/caught regularly. A
> couple hundred exceptions occur per hour and they're caught close to
> the point of origination. I'm trying to decide whether to refactor...
>
> What is the cost of throwing an exception in the CLR - relative to,
> say, a conditional statement? Are we taking talking 1+ orders of
> magnitude? Is there significant churn in the CLR? Are my timers and
> threads going to suffer drift or unnecessary swaps each time an
> exception get fired?

I would not worry about the cost of throwing/catching exception (although is
it not negligeable, probably at least 10 times slower than a test). I would
worry more about the design issue behind it.

Exceptions are nice to deal with "exceptional" situations. If you start to
use them to handle "normal" flow of control, you loose on several fronts:
* the "normal" code gets ugly and more difficult to read. You end up
replacing easy-to-understand if-then-else constructs by catch clauses that
discriminate on exception types.
* the code that deals with exceptional cases is difficult to analyze too
because it is polluted by catch clauses that deal with the "normal" logic.
So, for example, it gets difficult to guarantee that all exceptions (the
real ones, that correspond to exceptional cases) are properly logged and
reported to the user.
* program will be slower.

So, rather than worry about the performance of exception, you should worry
about the design choice itself.

>
> Thanks for anyone's input. I've spent time snooping the news groups
> and csharp.net, but haven't run into a great answer yet (besides
> "don't use exceptions for control flow" arguments :-)
>
> -Miyra
>
> ps: Developing with MS Visual C# NET.
>
> ps: Here are some links I found
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/dotnetperftips.asp
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/highperfmanagedapps.asp
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/scalenetchapt15.asp

Relevant Pages

  • RE: Can this cause memory leak ?
    ... No memory leak to worry about. ... it is inefficient and bad practice to catch exceptions ... during the normal flow of your code. ... > But I worry there is memory leak for lack the Deletecall. ...
    (microsoft.public.vc.language)
  • Re: System_SR_enu.cab
    ... meaningful text for exceptions. ... I'm certain it isn't "breaking" anything, ... so why worry about it? ... > But I do not have it as a reference on any of my projects! ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: Dubya beats dogg in the approval ratings
    ... insulted, with the exceptions of you, ... Not to worry, it keeps my ratings up. ... And I know it does some good for you to vent on me, ...
    (misc.news.internet.discuss)
  • Re: Using exceptions for early exit
    ... > would expect that people reading the code would /not/ expect exceptions to be ... Nor is the shape of the control flow a problem. ... My objections to control-flow-by-exception are twofold. ... First, there's efficiency. ...
    (comp.lang.java.programmer)
  • Re: Advice on handling multiple return values?
    ... I've found control flow difficult to ... understand when looking at code which used exceptions to handle ... errors (like errors on opening files, etc.), therefore you have to ... handle them for the most part, possibly in outer functions, thus ...
    (comp.lang.scheme)