Why are exceptions so rarely used in C++

I have been programming in C++ on and off for about 5 years, why have I never seen exceptions used other than exampl开发者_运维问答es for examples sake?

Observation bias at work here.

A significant fraction of C++ code is for systems programming and embedded systems. (After all, C++ is just one of many options for applications programming, and many of the alternatives have fancier RAD environments, but in systems work, it's often the highest level language for which a compiler is available, by a wide margin). And most embedded systems as well as a significant chunk of systems development work have constraints that rule out exceptions.

If because of your focus, you tend to search out this sort of code, it's entirely possible that the C++ code you've seen doesn't use exceptions.

That doesn't mean that there isn't C++ code using exceptions -- there is, and a lot of it. It may just not appear in code designed to solve problems that are interesting to you.

Exceptions are a fairly late addition to the language, so I believe many C++ developers have never learnt to use them properly, and may feel more at ease using traditional (C style) error handling techniques.

I personally think they are indispensable in handling constructor failures (that is the foremost reason they were added to C++ after all), but they also require the correct use of other advanced (YMMV) techniques like RAII or smart pointers to avoid resource leaks.

I have been programming in C++ on and off for about 5 years, why have I never seen exceptions used other than examples for examples sake?

I'm very curious about this. I'm very curious about this since in 1996. Sometime I think in 1996 C++ Exception Handling revolutionized the way I'm writing software. I remember that I was reading about C++ Exception handling and I immediately understood the implications. Within minutes I was testing what happens, if an exception is thrown from a constructor. Compilers for UNIX were not ready for C++ Exception Handling until G++ 3.0 I think (whe was this?). Destructors were called for not constructed memory locations (on the stack) (in case of some exception was thrown). Destructors were not called for successful constructed objects (on the stack) (in case of some exception was thrown). delete was not called in case of an object created with new threw an exception from the constructor. Compilers for Windows and OS/2 were ready in 1996/1997. They worked. I remember Borland C++ for OS/2 and IBM CSet2 and Windows Visual C++.

Finally there was a method to abort construction of an object. Finally one could allocate an object inside a constructor AND rely on the successful construction of this object in some other constructor. Somehow I found out about all the rules. Not from books! Years later books came out, claiming that C++ Exception Handling is a good way to catch array-out-of-bounds error or other problems for which I never stopped using assert. Finally there was an easy method to provide the caller with complex information about some error without relying on stderr. Finally one did not need to debug some complex piece of software to find out, what was failing.

I cannot take people seriously, which are not using C++ Exception Handling. It is impossible to check every fallible call. It is impossible to reach the same level of quality of software without using C++ Exception Handling. Why are such people still hired? Why are there still platforms, which do not provide C++ Exception Handling. I would never consider writing software for such a platform, in the same way I would refuse writing a complex application in assembly code.

Curious. I work in C++ regularly, and it's been at least ten years since I've seen any C++ code which doesn't use exceptions. Anytime you have to propagate an error up a significant number of stack frames, you use an exception.

Several reasons come to mind:

1. Exceptions shouldn't be very visible, since they are designed to be thrown deep in the bowels of a library and caught somewhere high up in the call stack (even as high as main()).
2. They are intended to signal exceptional (i.e., rare and unexpected) faults. For example, failure to open a file isn't particularly exceptional. So, by default, the iostream library doesn't throw an exception when it fails to open a file.
3. Exceptions are very expensive to throw, which encourages adherence to the design intent.
4. C++ libraries that throw exceptions don't interface easily with C programs.

I could say the same thing and it would not be biased a lot, if i define that this is true for a Microsoft world and RAD.

I think it is because today you don't use C++ programs per se but rather a mixture of high level language using C++ libraries. And often you have a managed-unmanaged boundary.

Throwing and catching exception through this boundary is like lighting a firecracker in you ass :) - [read mem leak or worse]

Moreover if you use COM objects you have to use COM exceptions, so the usage of standard C++ exception must reside internally in a often small library. In small libraries you dont have a need to use exceptions.

Because there is a huge discrepancy between "real-world" code and "text-book" code.

I work in a "large" software company and can honestly tell you that the stuff you see in production follows nearly 0% of the good practices you read about in good books.

Take Scott Meyers' Effective C++ book as an example. Should be a copy on every software engineer's desk, from east coast, to west.

Exceptions are too advance for beginners so these are not always shown in the examples, especially on books.

I'm speaking of desktop applications for Windows. In my observation (YMMV too), earlier phase of the development probably until initial releases. Many developers doesn't think of exceptions early on. That is why there are few codes with exception handling but if you had like 2 or 3 releases already or if your on maintenance phase, exceptions are being considered due to various deployment environments through error reports from customers.

Several reasons come to mind:

1. Exceptions shouldn't be very visible, since they are designed to be thrown deep in the bowels of a library and caught somewhere high up in the call stack (even as high as main()).

I don't know what you mean with "Exceptions shouldn't be very visible". But I agree that catch-blocks should be rare -- and they are usually in main.

1. They are intended to signal exceptional (i.e., rare and unexpected) faults. For example, failure to open a file isn't particularly exceptional. So, by default, the iostream library doesn't throw an exception when it fails to open a file.

that the iostream library does not throw exceptions makes it kind of unuseable. Hiding errors from the caller! This is so C like.

1. Exceptions are very expensive to throw, which encourages adherence to the design intent.

Usually Exceptions are for system calls failing. Since writing to a file or opening a file is not really inexpensive, one would not care about Exceptions being expensive. Also having to check for success is more expensive than using C++ Exception Handling. Usually one would not create a try-catch block inside a time critical part of code.

1. C++ libraries that throw exceptions don't interface easily with C programs.

What is C? Ah yes -- I remember -- something I gave up around 1996. Remember Turbo Pascal?

Exemptions are not used in examples because it is rarely the focus of many of the questions or something you want to know in the first place.