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?

closed as primarily opinion-based by gnat, mattnz, AProgrammer, Kilian Foth, MSalters Nov 5 '13 at 11:51

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 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 '13 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 '13 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 '13 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 '13 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 '13 at 8:20
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.

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

  • 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 '13 at 11:55
  • Any details on how it's known to be outdated? – Wilbert Nov 5 '13 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 '13 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 '13 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 '13 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.

  • 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 '13 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 '13 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 '13 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 '13 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 '13 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.

  • 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 '13 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 '13 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 '13 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 '13 at 3:31

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