On Sun, 25 Jun 2006 10:00:42 -0400, Beman Dawes <bdawes@acm.org> 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#Diagnosti...
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.