C++ exceptions vs. C# exceptions

Question

In an old blog entry titled Cleaner, more elegant, and harder to recognize, the author states:

In C++ it's not quite so bad because C++ exceptions are raised only at specific points during execution. In C#, exceptions can be raised at any time.

What exactly does he mean by that?

Answer 1

Maybe put it another way:

It is possible in C++ to write functions that offer the nothrow guarantee.

I don't know C#, and I'm pretty sure Raymond Chen does, so I accept his claim that "In C#, exceptions can be raised at any time". Therefore, you cannot write functions in C# that offer the nothrow guarantee.

In C++, nothrow functions are quite an important component of functions that offer the other exception guarantees. To make a strong guarantee (that is, to implement transactions), you usually need something like a nothrow swap, that executes more than one statement without interruption by exceptions. To make a basic guarantee, you need nothrow resource cleanup and you may also need short nothrow stretches of code in which your objects' states violate their class invariants.

Enumerating all the "specific points" in C++ that can throw an exception might be tedious, but in practice it's not that hard to write a short piece of code that definitely doesn't. If you can't do that in C#, that's an important difference.

If Chen's claim about C# is wrong, then it probably doesn't matter what he means. Because he's wrong.

On a full read of the article, I notice that he's mostly talking about example code being incorrect (with obvious implications for real code). So if his C# claim is incorrect due to some special cases of C# code that definitely doesn't throw, but such C# code never appears in tutorial examples, then he would still have an important point about the way the languages are taught -- examples that leave out essential stuff that you need to do to make the example code exception safe are probably bad examples, and they risk teaching bad habits. And unlike with error-code examples, the student (says Chen) can't tell at a glance that the example is bad, and hence might not realise that more work is needed to make them "not-bad".

Answer 2

First, I would hesitate to accuse Raymond Chen of confusing anything with anything.

I suspect he means that in C++, exceptions are only thrown where there exists a throw statement. As long as you go deep enough into your code and library functions, you can determine exactly where exceptions may be thrown from. On the other hand, in C# there may be exceptions thrown by the runtime environment at any time. For example, you could get a security exception trying to call any function in any other assembly.

Answer 3

I think he's talking about asynchronous exceptions, which in C# can be raised in one thread because of something that happens in another. (Note that one of the commenters on Chen's blog entry interprets what he wrote the same way, though unfortunately Chen doesn't respond to that.)

See, e.g., http://msdn.microsoft.com/en-us/library/system.threading.threadabortexception.aspx for an instance where one thread calls the Abort method of an object representing another thread, causing that other thread to get a ThreadAbortException.

Answer 4

He probably means that in C++ exceptions aren't thrown by the framework, but only from your code (or external code written by people who considered their code as "their own code"). In C#, exceptions can happen in the framework as well.

What I don't understand, however, is why the writer seems to prefer having exceptions raised only from your own code.