Boost logo

Boost :

From: Johan Nilsson (r.johan.nilsson_at_[hidden])
Date: 2006-11-10 03:49:31

Beman Dawes wrote:
> On 11/8/06, Johan Nilsson <r.johan.nilsson_at_[hidden]> wrote:


>> I'm trying to find the documentation for the Boost.System stuff - any
>> pointers?
> In the CVS Head, see libs/system/doc/error_code.html, and
> libs/system/doc/system_error.html
> Also see

Ok, so I've made a quick pass though the docs. A few questions and comments:

1) Are there any guarantees for the lifetime of the decoder references as
returned by error_code::get_decoders? Could I hold on to them "forever",
once retrieved?

2) I've implemented similar code previously, but only designed for
portability with linux and Win32. What I very often use, is something
corresponding to retrieving errno or calling GetLastError (on Win32).

With the current design, it is harder to implement library code throwing
system_errors (retrieving error codes) as you'll need to get the
corresponding error code in a platform-specific way. Or did I miss

I'd like something like this in the error_code interface:

class error_code {
static error_code last_error_code(error_category const& ecat);
static void last_error_code(error_category const& ecat,
error_code::value_type new_error_code);

Which would enable:

throw system_error(error_code::last_error_code(native_ecat), "Failed!");

of perhaps even:

throw last_system_error("Failed!");

I know it's not 100% natively portable, as e.g. OpenVMS does not have an
equivalent of Set/GetLastError - but at least using errno_ecat should be
universal, and using native_ecat could be implementation defined (or simply
use errno internally when nothing else is available).

3) Don't the static methods new_category and get_decoders belong to the
error_category interface, rather than error_code?

4) I'm wondering about best practices for how to use the error_code class
portably while maintaining as much of the (native) information as possible.
Ideally, it should be possible to check for specific error codes portably,
while having the native descriptions(messages) available for as much details
as possible. Using native_ecat and compare using to_errno?

5) Ideally, I think having error_code as an additional part of
std::runtime_error instead of having the separate system_error class would
make sense. A error_code feels more like a property of a runtime_error that
might or might not be set. Might not be practical though.

6) A "std::string error_category::description() const" method feels like a
good idea to add. Don't ask me for any specific reasons just yet.

7) The error_category management seems very simplistic, just a static
new_category(...) method. Did you think anything more about the management?
It is not very unlikely that independent components will need to use (and
therefore also add) the "same" category (e.g. winsock_category,
nt_native_category, getaddrinfo_category, ...). Would it be possible somehow
to access information on available error_categories to be able to avoid
insertion of new error_categories with equal properties? Just thinking out
loud here ...

8) An enumeration (or class with static constants) containing the available
standard posix error codes (as referenced in the docs) would be nice, e.g.
posix_error::xxx_errno, posix_error::yyy_errno, ...

9) I assume the category management is thread-safe. I saw nothing explicit
about that in the docs.

10) I'd also like an explicit guarantee that the implementations of
error_category/system_error/error_code should be error neutral - i.e., that
they don't affect the current values of e.g errno and GetLastError.

11) With reference to 10 above - a useful addition to the library would be
an "error_code_preserver" class, a RAII class that picks up the current
error code when created, and restores it on destruction. Very useful when
you want to implement your own error-neutral functionality (such as in e.g.
a logging framework). Perhaps nothing for the standard, but why not for

BTW, if you have implemented error_code::to_errno for native_ecat on Win32,
consider me suitably impressed.

Overall, this is for a very much awaited addition to Boost (and even more so
to the C++ standard, eventually). Looking forward to use it!


Johan Nilsson

Boost list run by bdawes at, gregod at, cpdaniel at, john at