Re: [boost] [system][filesystem v3] Question about error_codearguments

Subject: Re: [boost] [system][filesystem v3] Question about error_codearguments
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2009-10-29 10:24:47

Detlef Vollmann wrote:
> Stewart, Robert wrote:
> >
> >>From a debugging perspective, the exception will be thrown
> >> at the wrong point.
>
> What you would probably throw is not the original exception,
> but an exception objects of some type like 'unhandled_error'
> that has inside the original exception data.

That's fine, but then an exception isn't thrown at the point where the error was detected, so the stack frame giving context for the error is lost.

> For a lot of system level calls, you could get quite a number
> of different error codes.  Some of them are not really exceptional
> errors (e.g. EAGAIN) in a lot of contexts.  But it's up to
> the application what error codes represent exceptional
> errors and which don't.

That's an interesting notion.  I'm sure those in this discussion that want exceptions in all cases would expect different exception types to represent some of the types of errors that can occur.  Your approach will collapse them into a single type.

> So the call would be something like 'device.read(error_object, ...)'
> and error_object would have member functions to query for error codes,
> and the destructor would throw, if error_object would contain an error
> code that was not queried for.

One must check for each possible error individually in order to avoid an exception?  That doesn't seem beneficial.  There are many cases in which one wants to check for specific errors to handle locally and to throw an exception for the rest or just return a failure indication -- perhaps after logging the problem.  Thus, there should be a means to simply query generally for failure and have that prevent throwing an exception.

> But the basic problem of throwing exceptions from destructors exists,

Right.

> and is IMO a major flaw of how exception handling works in C++,
> but I don't think that this will change.

No, that isn't likely to change.  It would be a major refactoring of the mechanisms and concepts.

Ideally, what we want is a compile-time failure if the error_code isn't checked.  After all, the point is that we want to be sure that the caller gets an exception or checks for failure.  (We can't verify that the caller does anything appropriate in either case, of course. ;-)  That requires compiler support and there's precious little time to add that to C++0x, if any.  Therefore, we'll just have to make the best of things and, perhaps, guide the LWG in how best to use error_code.

~error_code() could test for a pending exception before throwing an exception.  If there is a pending exception, that means the stack is being unwound and the error_code shouldn't aggravate the situation by throwing its own.  Otherwise, it can throw in its destructor, right?  Given that the caller expressly asked for the function to throw no exceptions but populate an error_code, it isn't too much to expect that caller to check for an error, even when the error is to be ignored.  (Indeed, error_code could provide a constructor argument or member function indicating that the caller wishes to ignore the error.)

That still means that error_code is "magical," but if those not ready to understand its use simply call overloads that throw rather than take an error_code instance, there's no undue complication.

_____
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.