Boost logo

Boost :

From: Oleg Abrosimov (beholder_at_[hidden])
Date: 2006-06-29 13:12:06


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

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. One more point is that type safety is abandoned here
too. 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.

Best regards,
Oleg Abrosimov.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk