Re: [boost] [system][filesystem v3] Question about error_code arguments

Subject: Re: [boost] [system][filesystem v3] Question about error_code arguments
From: Beman Dawes (bdawes_at_[hidden])
Date: 2009-10-28 12:02:02

On Tue, Oct 27, 2009 at 9:44 AM, Stewart, Robert <Robert.Stewart_at_[hidden]>wrote:

> Peter Foelsche wrote:
> > "Beman Dawes" <bdawes_at_[hidden]> wrote in message
> > news:a61d44020910200815kedf3976t6e96a67e2f453271_at_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