Exception Cost: When to throw and when not to

re: Exception Cost: When to throw and when not to

Jim Argeropoulos — Fri, 19 Dec 2003 21:39:00 GMT

You said:
In the managed world, there isn't this
widespread notion of deterministic
destruction of objects. This means that
the static cost of exceptions can be quite
a bit lower,

Seeing that the new Managed C++/CLI coming in Whidbey will have deterministic finalization, will it return to the same level of cost as standard C++?

re: Exception Cost: When to throw and when not to

Jim Argeropoulos — Fri, 19 Dec 2003 21:50:00 GMT

In managed C++ I used to use stack based objects to avoid try/catch blocks when possible. The code was cleaner and there was no explicit set up of the try catch which was faster.

I now use a "using" when possible instead, and you mention that there is an associated try catch with it. I guess I knew that there was a try/catch underneath, but somehow I didn't want to admit it to myself. A bit disappointing that I only have cleaner and more reusable code with a "using". Ah, well. It is nice to have the feature.

re: Exception Cost: When to throw and when not to

Rico Mariani — Fri, 19 Dec 2003 22:06:00 GMT

Yes, deterministic destruction would increase the cost to the standard level. Naturally we're always trying to find clever ways to keep that to a minimum but even low(er) cost is more than none at all.

re: Exception Cost: When to throw and when not to

John Cavnar-Johnson — Fri, 19 Dec 2003 22:28:00 GMT

So, do you think you could speak to the folks who designed System.Messaging? That namespace abuses exceptions in the most horrific ways. For example, if you call a synchronous Receive or Peek method on a MessageQueue and you specify a timeout value, the object raises an exception when your timeout expires. That would be bad enough (raising an exception for an outcome that I actually asked for), but it raises the SAME exception for everything, forcing me to interrogate the MessageQueueErrorCode to distinguish between the expected result (the timeout) and all the real exceptional situations that might have occurred. Luckily for me, I use VB.NET, so I can use the "Catch ... When" syntax. I pity the poor C# coders who have to deal with this crap.

Rico on Managed Exception Costs

Ken Brubaker — Fri, 19 Dec 2003 22:29:00 GMT

re: Exception Cost: When to throw and when not to

Rico Mariani — Fri, 19 Dec 2003 22:31:00 GMT

Sadly, I have a very long list of people to speak to...

re: Exception Cost: When to throw and when not to

David Levine — Fri, 19 Dec 2003 22:36:00 GMT

The hidden exception usage case is a little misleading. When using try-finally constructs and flow control leaves the try block normally (i.e. no exception occurred) then you do not incur the overhead of the SEH stack walk that you would get had an exception been thrown and the finally block was executed on the 2nd pass as the stack was being unwound via a global unwind. There may be some overhead if bookkeeping is done to tables tracking the state of objects within the body of the method.

I'd be interested in how much overhead there is in a try-finally where an exception does not occur. It should be very low.

re: Exception Cost: When to throw and when not to

Rico Mariani — Fri, 19 Dec 2003 22:40:00 GMT

You are correct, in the normal case with the finally block and no exception all that has to happen is a fairly minor state change to indicate that the finally block need not be run. However it's not nothing and such state changes do add up.

In unmananged code you could think of each destructor as being in its own implicit finally block and you wouldn't be too far from the truth.

The fact that these implicit finally blocks can be absent in the managed world helps reduce the static cost.

re: Exception Cost: When to throw and when not to

Rico Mariani — Fri, 19 Dec 2003 22:48:00 GMT

By the way, I'd just like to say how much I appreciate the thoughtful comments and clarifications that my readers are making.

Thank you very much guys, it really helps the overall quality of the blog a lot. Even if it does mean a little egg on the face for me sometimes :)

Greater good and all that :)

re: Exception Cost: When to throw and when not to

RichB — Fri, 19 Dec 2003 23:02:00 GMT

We all appreciate the quality of your blog. That's why you're the #4 hit on Google for 'rico'.

re: Exception Cost: When to throw and when not to

Frank Hileman — Sat, 20 Dec 2003 18:08:00 GMT

We have been hit by exception overhead in a couple MS APIs.

System.Drawing routinely throws exceptions, which are often impossible to predict. Put a few hundred of these in a tight display loop... it becomes horrible. One example, is an extreme zoomout matrix, when displaying text. Throws an exception, but to predict when? Nearly impossible.

The DTE api (the VS automation object model) usually throws an exception to indicate an object cannot be found in a collection. Simply looking up a control on a command bar can throw an exception. This has also caused perf hits for us.

Thanks for the focus on this widespread problem! I hope it will lead to some changes in the MS libraries.

re: Exception Cost: When to throw and when not to

Dmitriy Zaslavskiy — Mon, 22 Dec 2003 23:57:00 GMT

As per Chris Brumme's note: There is also a cost related to the fact the some optimization are not being performed by JIT in the presents of catch

Fun with VB .NET and Managed C++

Ramblings of a Code Monkey — Tue, 06 Jan 2004 07:15:00 GMT

Unfortunately, it looks like both the FindFirstFile()/FindNextFile method that I mentioned ">yesterday and Richard's #003900">VB .NET suggestionDir() really just calls the Win32 API functions behind the scenes). In both cases, when the code is looking for all of the subdirectories...

If you think it will be at all normal for anyone to want to catch your exception, then probably it shouldn't be an exception at all.

Edgar S — Wed, 18 Feb 2004 05:24:00 GMT

re: Exception Cost: When to throw and when not to

Me — Thu, 27 May 2004 07:20:00 GMT

I guess myself the reason of such a big cost when throwing an exception.

When to create exception objects

Rico Mariani's WebLog — Tue, 13 Jul 2004 03:11:00 GMT

Exceptions

Bryan's Blog — Tue, 13 Jul 2004 23:28:00 GMT

re: Qualitative Code Differences in Managed Code

Rico Mariani's Performance Tidbits — Wed, 23 Feb 2005 04:07:00 GMT

re: Common Sources of Processor Performance Penalties: Five Issues

Rico Mariani's Performance Tidbits — Sat, 05 Mar 2005 09:35:00 GMT

re: Common Sources of Processor Performance Penalties: Five Issues

Rico Mariani's Performance Tidbits — Sat, 05 Mar 2005 09:37:00 GMT

The True Cost of .NET Exceptions

Rico Mariani's Performance Tidbits — Thu, 14 Sep 2006 23:41:10 GMT

Here's an article under Jon's Homepage that was just brought to my attention.&nbsp; It's an interesting...

Performance Guideline: Use TryParse Method to Avoid Unnecessary Exceptions

J.D. Meier's Blog — Thu, 05 Oct 2006 06:28:13 GMT

Prashant Bansode, Bhavin Raichura, and Girisha Gadikere teamed up with Claudio Caldato (CLR team) to

Still Learning » Blog Archive » Exception vs. Error Codes in C++

Still Learning » Blog Archive » Exception vs. Error Codes in C++ — Wed, 02 Jan 2008 05:26:20 GMT

PingBack from http://imehta.com/blog-ketan/?p=15

Is your app trying to tell you something?

Ahmeds' Random Expressions — Wed, 25 Mar 2009 08:52:59 GMT

Exceptions (unexpected errors) are a part of every application lifecycle. No matter how reliable your