On Tue, Oct 27, 2009 at 9:44 AM, Stewart, Robert <Robert.Stewart@sig.com>wrote:
Peter Foelsche wrote:
"Beman Dawes" <bdawes@acm.org> wrote in message news:a61d44020910200815kedf3976t6e96a67e2f453271@mail.gmail.com...
A POSIX sub-group is looking at C++ bindings for POSIX.
They are talking about a filesystem library binding at least loosely based on Boost.System, Boost.Filesystem, and C++ TR2.
In looking at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2838.html, "Library Support for Hybrid Error Handling (Rev 2)", they are concerned about specifying hybrid error handling like this:
What is the sense of a C++ interface, which does not throw on error?
Others noted embedded environments -- very important today -- but let's look at a broader case. Throwing an exception is extremely expensive for many reasons. Some applications encounter errors regularly and often due to the nature of their environment or context. Such applications, if errors were reported using exceptions, would have high or widely varying latencies and generally sluggish performance. If errors are relatively infrequent, then the cleanliness of writing code without error checking at every turn, and the zero or near zero overhead of exception handling code when no exceptions are raised, means using exceptions is nearly ideal. Eventually, however, there's a threshhold at which the frequency of exceptions, given the cost to throw them when they do occur, overwhelms the processing time. In that case, exceptions are a problem, not the solution.
Exactly. To put a number on the cost of using exceptions as a reporting mechanism, I've heard Bjarne Stroustrup say that measured experiments put exceptions as 1000 times as expensive as other return mechanisms, at least with some compilers. Another problem with exceptions is that when errors are the norm that must be handled immediately, code becomes to littered with try/catch blocks as to become unreadable and unmaintainable. These problems with exceptions aren't an issue in most C++ applications. But code dealing with low level I/O (networking, file systems) is at least one area where a mechanism other than exceptions is a necessity. That's what Rob is pointing out.
I think meanwhile (this is 2009) we should be over the "I hate C++ Exception Handling" thinking.
Perhaps there's room for other opinions on the use of exceptions now that we've moved beyond that phase and the "Exceptions are always the error handling scheme of choice in C++" phase?
This error_code scheme allows one to choose whether to get an exception or not. Thus, one chooses when the overhead of throwing exceptions is acceptable and when not. Surely that's not controversial.
One would hope not, since boost::error_code is part of C++0x and is already shipping with several standard library implementations. Thanks, --Beman