Re: [boost] [system][filesystem v3] Question abouterror_code arguments

Subject: Re: [boost] [system][filesystem v3] Question abouterror_code arguments
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2009-10-28 08:47:04

Andrey Semashev wrote:
> Stewart, Robert wrote:
> > Andrey Semashev wrote:
> >> Perhaps, we could mark the non-throwing overloads as deprecated in
> >> the Standard? Like strstreams, they are there but generally
> >> throwing overloads are more preferred.
> >
> > Why is it necessary to impose a single view on the
> > language?  Authors
> > often give advice and situations demand certain concessions.  Isn't
> > it reasonable to accommodate many use cases?  If you're too
> > restrictive, you make C++ less appealing and users will choose other
> > languages.  Is that helpful?
>
> I wouldn't say that it would narrow the language in some way.

It doesn't narrow the language per se, but the standard library is considered part of C++ and will make the language less broadly appealing if too restrictive.

> You still
> get the same functionality, only error reporting mechanism is in
> question. Using exceptions for this purpose is, well... following the
> language spirit, so to say, while mandating a dual approach
> honors code

I use exceptions a great deal.  I have nothing against them.  When appropriate, they make things much nicer.  However, there are real use cases, some already posted, in which exceptions are too costly, while for typical usage they are exactly appropriate.  You can choose just one or the other, alienating different groups, or you can provide both.

C++ includes, by reference, the C standard library, too.  Thus, all of those error code returning functions are considered part of the language.  For example, you wouldn't want reading from a socket to throw an exception when no character is available if working over a dial-up connection or slow WAN because delays are certain.  Furthermore, you can look at things in the C++ standard library and find error returns, too.  Thus, it is wrong to suggest that exceptions are in the spirit of C++ while error returns are not.  Both approaches have their place and should be applied wisely.

> diversity. I happened to support some code that used both
> exceptions and
> error codes for error reporting, and I must say it was a
> pain. I think,

Perhaps the code you used was inconsistent in its use of exceptions versus return codes, perhaps the philosophy was poorly documented, or perhaps your bias against return codes made the problem worse than it really was.  Your anecdote leaves little room for speculation beyond this.

> at least for educational purposes one form of functions (the throwing
> one) should be highlighted as preferred.

By all means, write books and tutorials, and otherwise teach newcomers to use the exception-based interfaces.  Until one understands the language well enough, and has been programming long enough, one can't judge the relative merits of return codes and exceptions to make a wise choice.  However, that doesn't mean exceptions should be proffered as the one true way of C++ error reporting.  Those that do understand, and have specific performance requirements, should be able to choose to forego the convenience of exceptions, and the safety of not being able to ignore them, when required.

The library author must consider whether each library function should throw an exception, return an error code, or provide both options.  During review, others may have differing opinions which may lead to rethinking the initial choice.  Eventually, a library error handling philosophy will emerge and will inform the author for new functions as well as the library's users to know what to expect in each case.

In Boost, lacking any coding guidelines for error handling, you can expect different libraries to follow different philosophies.  In the C++ standard, you should expect consistency throughout.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.