Detlef Vollmann 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'
Stewart, Robert wrote: 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
Stewart, Robert wrote: 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