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

Subject: Re: [boost] [system][filesystem v3] Question about error_code arguments
From: Detlef Vollmann (dv_at_[hidden])
Date: 2009-10-30 21:53:22

Stewart, Robert wrote:
> 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.
 From a pedantic point of view I could argue that the exception
is that the error wasn't handled, and the context of that exception
would be preserved.  But I admit that the really interesting thing
is where the original error occurred, and that is lost.
But if we're talking about system calls (and this is what I'm talking
about), then the exception would only be thrown at the point of the
system call anyway.  So if the system call returns a 'poisoned'
error object that (possibly) throws at destruction, that shouldn't
be far from the failing system call, so you don't loose much of
the context.

>> 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.
Separate exception objects are the old times.
Now we have exceptions like regex_error, future_error or system_error,
whose sole purpose is to wrap a lot of different errors into one
exception.

>> 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.
The idea is that you check for things that are not exceptional, and for
everything else an error is thrown.
But of course there would also be an equivalent for
'is_error_condition_enum'.

> 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.
No, only non-exceptional "errors" should be checked, all others throw
an exception.
Especially in system level code, it's really the application that
defines what errors are exceptional and what "errors" are to be
expected.

> ~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?
In theory, yes.  But that would violate a lot of exception safety
guarantees.

   Detlef