Boost logo

Boost :

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
>> >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
>> const path & path2() const; // argument 2 to function; may be
>> 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
>error code ("ENOENT" for example, or
>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
>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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at