I Take Exception To That


/>

 

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
programmin
g — attempting to mix the style appropriate to one in another
is a recipe for unmaintainable code.

Comments (5)

  1. RJ says:

    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.

  2. Eric Lippert says:

    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.

  3. Siew Moi Khor says:

    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

  4. Ed Ball says:

    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.

  5. Anonymous says:

    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 🙂