From: Gennaro Prota (gennaro_prota_at_[hidden])
Date: 2006-06-25 13:50:10
On Sun, 25 Jun 2006 10:00:42 -0400, Beman Dawes <bdawes_at_[hidden]>
>The filesystem proposal accepted by the LWG for TR2 also includes a
><system_error> header with a bit of error reporting machinery.
>particular, class error_code to encapsulate error codes from the
>operating system and class system_error to be thrown by exceptions.
I've just looked at this paper, but not at the code (I'm working
contemporarily on three things now, so better I don't add a fourth
:)). Here are my "off the top of my head" remarks:
* something I've remembered of when seeing the names "system_error",
"error_code": why not "file_system"? (maybe this was already discussed
in the filesystem library review, but I don't recall)
* the name system_error_type is a bit misleading to me, as it seems to
refer to the type of system_error (i.e. system_error :)) not to the
type used by the OS API. Maybe it could be renamed to
or something like that?
* please, don't "hardcode" the usage of std::string and std::wstring;
I'm noticing this is happening everywhere in the standard, including
TR1, TR2 and one of the library issues about std::bitset<>; as James
Kanze made me notice, there's no conceptual reason why strings and
std::bitsets (or system_error, of fstreams) should know about each
other: if one wants the "textual representation" of an object the
idiom to use is operator<<, which is also a standard "name" suitable
for generic programming; obtaining the textual representation is a
matter of formatting and there's no reason why one should have e.g.
to_string() rather than to_ber_encoding() or to_xml(). Not to speak of
the fact that a conversion to string may require a locale object,
which you automatically get if using a stream.
Just to make an example: supposing one want to implement
ipv4::to_string(), what should be done with octets whose value is less
than 100 or less than 10?
As you see, this is formatting.
This is a Java design error that C++ should not repeat (think also of
Java's hashCode() -that's not different from to_string(), actually; a
class shouldn't know about strings more than it knows about hash
* "The class error_code defines the type of objects used to
identify specific errors originating from the operating
Who says this is a numeric code? It could be a handle, for instance,
or any kind of opaque object. Why not calling the class "error_id"?
* many constructors are not explicit; is that intentional?
* system_message is a particular beast: since it is likely to be used
in very unstable situations I think the remark about avoiding
std::basic_string holds even more. Here I would definitely use an
array of chars.
Of course the standard doesn't usually say how you should implement
the class, but in this case it should make clear that std::string
cannot be used; there should IMHO be no append and probably the
message formatting should be a nothrow operation
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk