[boost] [system] Was: Re: [asio] Breaking changes committed to cvs HEAD

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:
>>

[snip]

>> 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
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2066.html

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 
something?

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 
Boost.System?

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!

Regards,

Johan Nilsson