Re: [boost] Filesystem Library mini-review

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-12-17 13:17:52

At 11:50 AM 12/17/2002, Peter Dimov wrote:

 >From: "Beman Dawes" <bdawes_at_[hidden]>
 >> At 10:18 AM 12/17/2002, Peter Dimov wrote:
 >>
 >>  >The main problem is that I don't really know the answer. I can tell 
you
 >>  >what doesn't work, but I don't know yet what works. :-)
 >>
 >> How about these member functions (in addition to what()):
 >>
 >>     int         native_error() const { return m_sys_err; }
 >>      // Note: a value of 0 implies a library (rather than system) error
 >>
 >>     error_code  error() const { return m_err; }
 >>
 >>     const string & function() const;
 >>       // name of the function throwing the exception
 >>
 >>     const path & path1() const; // argument 1 to function; may be 
empty()
 >>     const path & path2() const; // argument 2 to function; may be 
empty()
 >>
 >> Code catching the exception with then have all the information that was
 >> available at the point the exception was thrown.
 >
 >I assume that for
 >
 >boost::filesystem::rename("this", "that");
 >
 >function() would return "boost::filesystem::rename", path1() - "this",
 >path2() - "that",

Yes, exactly.

 > and error() - ENOENT (or its equivalent).

error() returns the generic error code, so it would return 
filesystem::not_found_error. native_error() returns the operating system 
error code, so for POSIX would return ENOENT, or ERROR_PATH_NOT_FOUND (or 
similar) on Windows.

 >This looks good. In general, I have found that I need:
 >
 >- what failed (operation, arguments)
 >- why did it fail (error code)
 >
 >and this interface seems to provide them.
 >
 >A nice addition would be a function returning a string that identifies 
the
 >error code ("ENOENT" for example, or 
"boost::filesystem::not_found_error",
 >if POSIX values aren't used); it's not hard to write one, of course, but
 >the upshot is that the code that reports the error doesn't need to change
 >when new error codes are introduced:
 >
 >std::cerr << translate_text(ex.error_str()) << std::endl;
 >
 >and only the translation table (a data file, no recompilation) needs to 
be
 >updated. But it's not _that_ important. :-)

Um... Rather than fatten the interface to filesystem_exception further, the 
code->string translation could be provided as a free function. That way you 
don't have to pay for it if you don't use it.

Let me think about that a bit.

--Beman