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?

Maybe ask him. Even if you hold with Barthesian "Death of the Author", it can be worth asking the person who wrote something, what they meant. — Jon Hanna, Jun 14 '12 at 11:23

score 4 · Answer 1 · answered Jun 14 '12 at 08:34

4

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.

answered Jun 14 '12 at 08:34

Greg Hewgill

951,095
183
1,149
1,285

He'd of course be wrong since the `new` operator can throw an exception. – edA-qa mort-ora-y Jun 14 '12 at 08:35
True, but you can also find all the places where `new` might be called just as easily as you can find all the `throw` statements. – Greg Hewgill Jun 14 '12 at 08:36
although not part of standard c++, many implementations optionally allow for things like division by zero to throw exceptions too. – PlasmaHH Jun 14 '12 at 09:18

Steve Jessop · Accepted Answer · 2012-06-14T11:10:21.283

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".

score 2 · Answer 3 · answered Jun 14 '12 at 08:34

2

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.

answered Jun 14 '12 at 08:34

Gareth McCaughan

19,888
1
41
62

Here it would be misleading since C++ allows for signals to be raised at any time. These are perhaps not exceptions, but they can happen at any time in any thread. – edA-qa mort-ora-y Jun 14 '12 at 08:42
@edA-qa mort-ora-y: I think that sort of doesn't matter, because you can refrain from installing any signal handlers that will alter your thread's flow of execution. But sure, libraries that you use might ruin your day. – Steve Jessop Jun 14 '12 at 09:08
@SteveJessop, I just noted this since combined with the comments on Greg's answer it isn't clear that the original article author is actually well educated on the subject, or has failed to adequately say what he means. – edA-qa mort-ora-y Jun 14 '12 at 11:06
In general, Raymond Chen is very well educated indeed on the subjects he writes on, at least from a Microsoft-specific perspective. – Gareth McCaughan Jun 14 '12 at 11:35

score 0 · Answer 4 · answered Jun 14 '12 at 08:32

0

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.

answered Jun 14 '12 at 08:32

SimpleVar

14,044
4
38
60

1

What do you mean by "framework" in the case of c++? The standard library as well as e.g. operator new can throw in c++ too. – PlasmaHH Jun 14 '12 at 09:20

C++ exceptions vs. C# exceptions

4 Answers4