Re: [boost] [system] system_error first draft

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

>The filesystem proposal accepted by the LWG for TR2 also includes a 
><system_error> header with a bit of error reporting machinery.

Great.

>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

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

 native_system_error_type

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?

a) 192.168.0.10
b) 192.168.0.010
c) 192.168.000.010
....

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

* "The class error_code defines the type of objects used to
   identify specific errors originating from the operating
   system."

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

--Gennaro.