I Take Exception To That

I Take Exception To That

  • Comments 6

  Joel and Ned are having a spirited debate over the merits of exception handling.  Oddly enough, I agree with both of them.


The only time I do programming in C++ is to write COM code, and COM and exceptions do not mix.  The only way to make COM and C++ exceptions mix is to use smart pointers, and as I've already discussed, that only makes the situation worse by introducing subtle, impossible-to-find-and-debug bugs in the error handling.  When I write COM code every function call returns an HRESULT and I carefully ensure that if there is an error, then everything gets cleaned up properly.  COM is fundamentally an environment which is based on error return values for error handling.  Any additional error state can be provided by stateful objects. 


But the .NET CLR is a completely different environment, one with an exception model built deep into the runtime itself and into the framework.  You'd be crazy to not use the exception model in a fully garbage-collected environment like the CLR.  I write a lot of C++ and C# code that has to work together via Interop; ALL of my C++ functions returns an error code, and NONE of my C# functions do.  That is not to say that there is no error handling in my C# code -- far from it!  My code is chock full of try-catch-finally blocks to deal with errors.


Programming languages and object frameworks are tools that afford different styles of programming -- attempting to mix the style appropriate to one in another is a recipe for unmaintainable code.

  • I've been looking for some information on the performance of Exceptions in the CLR. They always used to be quite expensive in Java (from what my poor memory remembers). I would be worried that I was taking a performance hit for something that I could do in another way - not that it *really* matters in the stuff I do, but if there were lots and frequently (apart from having a broken install) I would be peeved.
  • There are two aspects to exception performance. First, what is the additional over-all burden imposed by exceptions. Second, what's the cost of throwing an exception? As for the first: exceptions aren't cheap anywhere. C++ exceptions are quite expensive in fact -- take a look at the codegen for the same method with exception handling turned on and off if you want to see what I mean. But in the .NET framework, there is no way to "turn off" exceptions. You're stuck with this infrastructure. If you can't change it, there's no reason to worry about it. The question is not "are exceptions fast enough in the CLR?" but rather "is the CLR fast enough?" The second concern I don't care about one bit. Exceptions are, by definition, exceptional. When one of my programs gets an exception, almost always it is either doing something incredibly expensive already (in which case the cost of the throw is irrelevant) or we are going to report the exception to the user (in which case the program is going to come to a screeching halt anyway.) Either way, the per-throw cost is unimportant.
  • RJ, you might find Chris Brumme's excellent post on the exception model useful: http://blogs.gotdotnet.com/cbrumme/commentview.aspx/d5fbb311-0c95-46ac-9c46-8f8c0e6ae561
  • Early in the process of developing our application (which uses tons of COM), we decided to enclose every non-trivial COM method implementation with a try-catch block, and we used a C-style macro to generate code that catches _com_error, std::bad_alloc, std::exception, and even "...". The macro logs the exception and returns an appropriate HRESULT. Not pretty, but at least we didn't have to give up exceptions.
  • Chris Brumme's article looks very interesting. I think it might be stretching the meaning of the word article a little, I'll bookmark it and read it when I've got a weekend free :)
Page 1 of 1 (5 items)