Re: [boost] Filesystem Library mini-review

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-12-17 11:50:18

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", and error() - ENOENT (or its equivalent).

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

Another interesting issue is to decide which of "what" or "why" (if any) to
expose using the type of the exception. The standard library hierarchy tends
to answer the "why" question, but there is no definitive rule which is best.
Code that catches an exception locally typically needs the "why" part, but
distant handlers are more interested in "what".