locked
Throwing Exceptions expensive? RRS feed

  • Question

  • User2090782264 posted

    Consider the following example:

    public string DoSomething()

    {
          throw InvalidArgumentException();

     

    public void CallDoSomething()
    {
         try
         {
                 DoSomething();

         } catch (Exception ex)
         {
             //Do nothing
          }
    }

     

    Since the code above does NOT actually throw an exception (because it is caught by the caller), is it still expensive? I thought that exceptions are ONLY expensive if it actually throws and initiates the debugger/prompts etc

    Sunday, November 21, 2010 11:31 AM

Answers

  • User300685930 posted

    DoSomething() is actually throwing an exception so it does slow you down (even if you don't do it yourself in catch).  Throwing exceptions slows you down whether or not debugging is happening.  Put it in a loop and time it and you will see for yourself. 

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Sunday, November 21, 2010 11:57 AM

All replies

  • User300685930 posted

    DoSomething() is actually throwing an exception so it does slow you down (even if you don't do it yourself in catch).  Throwing exceptions slows you down whether or not debugging is happening.  Put it in a loop and time it and you will see for yourself. 

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Sunday, November 21, 2010 11:57 AM
  • User712082397 posted

    public string DoSomething()

    {
          throw InvalidArgumentException();

    This is definitely expensive than the other piece of code that you mentioned.

    What you have to do is find a fine balance between your requirements and implementation without taxing the performance of the system.

    Being expensive does not necessarily mean that it's bad.

    Monday, November 22, 2010 9:04 AM
  • User-952121411 posted

    Since the code above does NOT actually throw an exception (because it is caught by the caller), is it still expensive? I thought that exceptions are ONLY expensive if it actually throws and initiates the debugger/prompts etc

     

    The exceptions are expensive in creation and being thrown no matter where they are caught (but not to say they are not warranted because they are needed).  If you want some low level details, check out a few of these articles from the MSDN Blogs:

    Exception Cost: When to throw and when not to:

    http://blogs.msdn.com/b/ricom/archive/2003/12/19/44697.aspx

    The True Cost of .NET Exceptions:

    http://blogs.msdn.com/b/ricom/archive/2006/09/14/754661.aspx

    http://blogs.msdn.com/b/ricom/archive/2006/09/25/771142.aspx

     

    Thursday, November 25, 2010 1:18 AM
  • User-1308667499 posted

    On a side note, catching the general "Exception" is usually considered bad practice. 

    http://stackoverflow.com/questions/426346/is-this-a-bad-practice-to-catch-a-non-specific-exception-such-as-system-exception

    Wednesday, December 1, 2010 11:51 AM
  • User-525215917 posted

    In theory, yes it is bad practice. In practice you don't have other option sometimes. There are two important Exception subtypes: SystemException - should only be used by framework libraries, ApplicationException - should used for exceptions in your apps. So far, so good, but ... these rules are not followed by framework library developers nor application developers. So there are situations where all you have to handle is Exception class that for some reason is not marked as abstract.

    Thursday, December 2, 2010 4:46 AM