Boost logo

Boost :

Subject: Re: [boost] [system][filesystem v3] Question abouterror_code arguments
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2009-10-27 13:43:47

David Bergman wrote:
> On Oct 27, 2009, at 12:50 PM, Peter Foelsche wrote:
>>> Others noted embedded environments -- very important today -- but
>>> let's look at a broader case.
>> I was talking about C++.
>> C++ includes exception handling.
>> C++ without exception handling does not make any sense,
>> as one cannot perform a fallible resource allocation inside a
>> constructor.
> There is no official recommendation for the language in-between EC++ and
> C++ - C++ minus exception handling - AFAIK, but it is no secret that
> Boost is targeting that "language" as well, and also C++/CLI to some
> extent.
> Strange as it might seem, quite sensical programs have been created in
> this unnamed language, even though one cannot use the sometimes nifty
> feature of throwing in a constructor. So, I fail to see how it "does not
> make any sense."

I don't want to comment the ASIO-related argument, neither I want to
convert anyone to anything.

What I want to point out is that IMO, exceptions are sometimes
undeservedly ignored for different reasons. One of such reasons is
developer's commons, if he got used to code without exceptions and/or
cannot use them properly for the lack of knowledge. Another reason is
attempt to achieve overzealous portability, be that ancient buggy
compilers from the dawn of C++ or some exotic platforms without
exceptions support. All these reasons are valid, at least for now.

But for how long? Developers eventually learn things or move to other
languages (C?). Ancient compilers die, new ones become more popular and
more efficient. Exotic platforms also either tend to decease or evolve.
In my mind, error handling through exceptions should become more
preferred over time. Expressing and honoring this tendency in the
Standard for the coming 5 years may not be such a bad idea after all.

Boost list run by bdawes at, gregod at, cpdaniel at, john at