Re: [boost] [system] system_error first draft

From: Beman Dawes (bdawes_at_[hidden])
Date: 2006-06-25 15:25:45

Gennaro Prota wrote:
> 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?

I was also quite unhappy with the names in the proposal to the 
committee. Thus the version in the Boost vault has what I hope are 
improved names, less likely to cause confusion.

If Boosters like the new names, I'll propose them to the committee. The 
intent is synchronize both versions so they use the same names.

So please looks at the new names and see if you think they are an 
improvement.

> * please, don't "hardcode" the usage of std::string and std::wstring;

When dealing directly with the operating system, it is hard to see how 
to avoid that. Please be a bit more specific, and suggest alternatives.

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

That is beyond the scope of anything I can deal with here. You need to 
write a paper for the committee, identifying specific places in the 
standard (or TR1/TR2) where you think that is happening, and where 
possible suggest solutions to the problems you identify.

> 
> * "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"?

The native operating system's sysno_t is implementation defined. I'll 
take a look, but it should be possible for it to be something other than 
a numeric type.

> * many constructors are not explicit; is that intentional?

I'm not sure which constructors you are looking at. The only converting 
constructor I see is already explicit.

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

I'll review that. You may be right.

Thanks,

--Beman