Re: [boost] [system] system_error and exception handling paradigm

From: Beman Dawes (bdawes_at_[hidden])
Date: 2006-07-11 09:21:13

"Oleg Abrosimov" <beholder_at_[hidden]> wrote in message 
news:44A409E6.9000600_at_gorodok.net...
> Beman Dawes wrote:
>> The filesystem proposal accepted by the LWG for TR2 also includes a
>> <system_error> header with a bit of error reporting machinery. In
>> particular, class error_code to encapsulate error codes from the
>> operating system and class system_error to be thrown by exceptions.
>>
>> See
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1975.html#Diagnostics-library
>>
>> The plan is to use these classes uniformly in TR2. Presumably we will
>> want Boost implementations, and use them in other Boost libraries
>> besides Boost.Filesystem.
>>
> > [snip]
>>
>> And any other comments are welcome!
>>
>> --Beman
>
>
> Hello Beman!
>
> The N1975 proposal has a section called "Important Design Decisions". It
> is a very good place to put a rational why you've chosen the error
> reporting strategy with system_error.
>
> currently, it has only one sentence "Because filesystem operations often
> encounter unexpected runtime errors, the library by default reports
> runtime errors via C++ exceptions, and ensures enough information is
> provided for meaningful error messages, including internationalized
> error messages."
>
> It is not enough to understand why you don't follow the way of other
> portable file system frameworks. For example, in java language there are
> IOException and its descendants like FileNotFoundException. It can be
> said that it follows the usual OO-exception handling mantra - define a
> hierarchy of exception classes and use them to report error conditions
> from your functions. Furthermore, it can be said that it is a way to
> abstract low-level system errors and provide only high level logical
> errors (or exceptions).

Yes, I'm well aware of that approach and was one of the participants in LWG 
at the time that approach was designed back in the early 1990's.  A strength 
of such a high level approach is that it abstracts away a lot of differences 
between operating systems. But sometimes programmers need to deal with those 
lower level details. The set of error conditions that has to be dealt with 
is also open ended, and exception hierarchies where there is one exception 
for each error type have trouble dealing with that. There is also the issue 
of interface bloat - there are a very large number of potential errors, and 
having an exception type for each one of them become unwieldy.

> It is clear from n1975 that you abandoned the OO approach and fall back
> to the C-style error reporting and handling. Yes there are exceptions,
> but no hierarchy. And exception handling is done by dispatching on a
> base of error codes but not on exception types. So, it is not really far
> from "C" I believe.

That was the intent. To provide a C++ interface that is higher level than 
the C interface, but not so high level that programmers can't get at the 
details.

> One more point is that type safety is abandoned here  too.

Not sure what you mean here. Could you give an example?

 >I should add here that I agree with your decision, but I think that
> it shouldn't be made implicit, without a really good explanation and
> rational. The reason is simple: it changes the paradigm that is written
> in all OO and/or C++ books.

The plan is to take the feedback from Boosters, improve the details of the 
interfaces, and present a proposal to the  LWG refining the work that has 
already been accepted. I'll try to add more rationale to that document.

Thanks,

--Beman