6

AFAIK, a lot of C++ projects don't allow exceptions and deny them in coding guidelines. I have a lot of reasons, for example, exception is hard to handle correctly if your binary needs to be compiled by separate and different compilers.

But it doesn't fully convince me, there is a lot of projects which are just using one compiler. Compared to C++, exceptions are heavily used in C# and Java and the reason can only be that exception are not bringing enough benefit.

One point is debugbility in practice. Exception can not get the call stack in C++ code, but in C# and Java you can get the call stack from exception, it is significant and makes debugging easier. No-callstack is not the fault of the exception, it is the language difference, but it impacts the exception usage.

So what's the reason that exceptions are frowned upon in c++ programs?

Improve this question
6
  • 6
    Vote to close: The answer is primarily option based, and more than likely the premise of the question is flawed - Show us evidence C++ Exceptions are not used much?
    – mattnz
    Nov 5, 2013 at 8:54
  • 1
    Also, the idea that you can't get a stack trace is a bit flawed; I know gdb and Visual Studio both can.
    – MSalters
    Nov 5, 2013 at 11:52
  • @MSalters, As link given by BЈовић Shows. Yes, you can got the call stack at runtime only if you have symbols, else you can only have frame addresses. But always distribute the symbols with binary together is not practicable, and pass the address manually is not convenient enough compare to Java or C#.
    – ZijingWu
    Nov 6, 2013 at 2:26
  • @mattnz, It is fact C++ exception are not used as much as in Java. You can search in google for debat about Error code VS Exception, most of them are talk about C++. Coding guidline of Google prohibit it and AFAIK, some Microsoft team also prohibit it for C++ code. And even STL provide no-exception way of usage. So it is fact, and there must be some reason behind it, instead of just opinion-based reason.
    – ZijingWu
    Nov 6, 2013 at 2:49
  • @ZijingWu: Of course it's not hard to distribute symbols. C# and Java do it all the time. Microsoft bans C++ exceptions in drivers, but that's an environment in which all of C# and java are banned.
    – MSalters
    Nov 6, 2013 at 8:20

4 Answers 4

Reset to default
10

There are two main reasons why exceptions in C++ are often shunned.

  • Legacy code
  • Fear/uncertainty/doubt (FUD)

Exceptions require awareness that, even if you do not throw an exception yourself, any function you call could throw an exception and you should be able to deal with that gracefully (at the very least, without leaking resources). When exceptions were first introduced in C++, this awareness did not yet exist by many of the C++ developers. If you add to that that a lot of existing C code has been ported to C++ and that the C++ runtime environment did not offer that many aids to help you avoid memory leaks, you get a vast amount of legacy C++ code that is not exception safe.

The initial lack of awareness about how to write exception-safe code also cause a lot of fear, uncertainty and doubt, because exceptions worked so differently from the familiar flow control mechanisms that a lot of the common wisdom for writing robust applications had to be critically re-evaluated.

None of these problems exist for C# and Java because those languages only came along when exceptions were already much better understood, they have garbage collection so there is one major resource you don't have to look after that carefully and they don't have pre-exception legacy code.

Improve this answer
6

The google C++ style guidelines say:

We do not use Exceptions.

In that guide, you can find a list of pro's and con's of exceptions in C++, and a discussion of why they decided against using them. I feel these apply to many projects, not just google-originated ones.

Basically, the reason is "compatibility with legacy code".

Improve this answer
6
  • 8
    That's a known outdated style guide. Even for legacy code, it's sufficient to have the rule "we don't let exceptions escape".
    – MSalters
    Nov 5, 2013 at 11:55
  • Any details on how it's known to be outdated?
    – Wilbert
    Nov 5, 2013 at 12:31
  • 2
    Interestingly enough, the discussion of exceptions in that style guide includes the sentence "Things would probably be different if we had to do it all over again from scratch." Looks to me like Google considers not using exceptions from the start to have been a mistake.
    – Evicatos
    Nov 5, 2013 at 19:11
  • @Wilbert If you read carefully the linked page, you can see : "Things would probably be different if we had to do it all over again from scratch.". My understanding of that is they would use exceptions.
    – BЈовић
    Nov 6, 2013 at 12:40
  • @BЈовић Well, it depends what they mean with 'all over'. I understood it to be their current software stack. So (as in my answer) the reason is legacy code, which doesn't make the guide outdated. Even today, that's still a valid reason. Having said that, I am a big proponent of Exceptions and use them in all my code. :)
    – Wilbert
    Nov 6, 2013 at 12:57
2

a lot of C++ projects don't allow exceptions and deny them in coding guidelines

I would say ignorance. They do not understand what exception means, and they even measure how long it takes to unwind the stack.

Exception are not bringing enough benefit.

The alternative to exceptions is kind of spaghetti code, and greatly increased complexity. Which directly translates to time/effort/money.

For example, what do you do if an object's construction fails?

By only adding exceptions to a c program (and nothing else from c++), the complexity would be greatly reduced.

Exception can not get the call stack in C++ code

It is possible to get the backtrace, and this answer shows how to do it.

Improve this answer
6
  • The better argument is how much time is spent NOT catching an exception versus how much time is wasted checking error codes in success situations.
    – MSalters
    Nov 5, 2013 at 12:00
  • @MSalters That as well. I was thinking more of a time wasted in additional effort in development due to increased complexity.
    – BЈовић
    Nov 5, 2013 at 12:07
  • @MSalters That doesn't make sense -- to throw the correct exception (and to respond with the correct catch) the underlying code still has some if statement comparison checking to do -- I can't see how exceptions can be in any way cheaper than, say, integer return codes.
    – bobobobo
    Dec 10, 2013 at 23:47
  • So you have: if( fn() == ERR_NOT_CONNECTED ){ handle ; } else { continue_with_code ; } vs try{ fn(); continue_with_code() ; } catch(...) { handle ; }. But won't the conflict resolution mechanism that jumps you into the correct catch block have similar cost to your if statement anyway?
    – bobobobo
    Dec 10, 2013 at 23:50
  • @bobobobo No, it will not, since you have to check the error at every level. That not only makes the program much more complex, but it also introduce minor runtime penalty. Now if you can handle the error where it occurs (for example open a different file, if one is not available) then you are not going to throw an exception. That is why (for example) std::fstream doesn't throw byy default.
    – BЈовић
    Dec 11, 2013 at 5:51
0

The reasoning I followed to choose not to use exceptions in C++ code unless no viable alternative was immediately visible was the overhead of managed resources and breaking the normal flow of things.

http://ptgmedia.pearsoncmg.com/images/020163371x/supplements/exception_handling_article.html

The article in the above link is a reproduction of something that was first published in 1994 C++ Report by Tom Cargill.

I would say it is just harder to do Exception handling properly in C++ code and bugs can be very subtle hard to find. As Tom Cargill writes

The really hard part of using exceptions is to write all the intervening code in such a way that an arbitrary exception can propagate from its throw site to its handler, arriving safely and without damaging other parts of the program along the way.

Improve this answer
4
  • 5
    You're relying on an argument that's 19 years old, about a language that wasn't even standardized at the time. In particular, Cargill's argument was entirely refuted by RAII, and all subsequent standardization was done with RAII in mind. Of course it breaks the normal flow. Exceptions by definition are exceptional, not normal. Error codes mix normal and exceptional code, and mixing unrelated things is exactly what causes confusion.
    – MSalters
    Nov 5, 2013 at 11:58
  • I agree that it has become better and RAII is a good practice, but I like the old reference still having that valid argument I quoted. The google reference (see other answer) says something similar: Exception safety requires both RAII and different coding practices. Lots of supporting machinery is needed to make writing correct exception-safe code easy... It's a matter of opinion, I choose avoidance when possible.
    – Wouter Simons
    Nov 5, 2013 at 13:00
  • 2
    No, the quote truly became outdated. E.g. the standard carefully specified exception in ctors so that Cargill's problem goes away if you use RAII. Keep in mind that you need an ad-hoc technique if you use a mechanism other than RAII, it's not like you suddenly get Garbage Collection when you ignore exceptions.
    – MSalters
    Nov 6, 2013 at 1:11
  • I remember programming C++ in the early 1990's. In 1994 you were lucky to get a "C with Classes" C++ program to compile and run without hitting a compiler bug. Exceptions were no exception to the rule "don't use any language feature that has been added in last 2 releases". Enough of us got burnt badly enough that it was years before we would rely on C++ doing what the standard said it would. RAII was often practiced - by mistake - we worked out what hurt and what didn't, so tended do things that did not hurt too much...
    – mattnz
    Nov 6, 2013 at 3:31

Not the answer you're looking for? Browse other questions tagged or ask your own question.