Beman Dawes wrote:
On 11/8/06, Johan Nilsson <r.johan.nilsson@gmail.com> 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