|
Boost : |
From: Martin Brown (martin_w_brown_at_[hidden])
Date: 2003-01-12 06:25:49
Hi,
I would second the approach below. If I can get to
the native error code, then I can use FormatMessage()
or strerror() to get to the platform error message,
localised if necessary. I am not so interested in
the name of the function throwing the exception - I
tend to use a logger with a stack-trace built in.
The parameters are nice if a lightweight mechanism can
be found for recording them.
As regards error code collisions, library and OS
errors etc: I think there is a split in the way
exceptions are used. Assuming that the OS is
complex, thus there are many possible failure
conditions, _any_ error code could returned by _any_
API function. If the code is trying to recover from
this, then all we (programmers) are interested in are
the broad categories of the error, so we can code
appropriate recovery actions. If we are not
interested in recovering (e.g. we didn't expect
anything to go wrong, so we need to know if it did)
then all we want to do is dump as much information in
front of the user and rollback the operation. I
would say that exception types should be used for
categorising exceptions for the purposes of recovery,
but that the OS error code should be available when we
have to present the information to the user. A
sub-class could be used to separate library errors
from OS errors.
Personnally, I have never found what() much use for
anything except debugging. The standard does not
promise anything about its contents; and even if the
string is useful, it would have to be parameterised,
translated and encoded appropriately for word-wide use
- non trivial and a huge maintenance effort.
Thanks - I really appreciate the work you are doing,
Martin
---- Beman Dawes wrote: Peter Dimov and I went back and forth about this for the filesystem library and decided: ... what() // from std::runtime_error. Implementation provides // a very explicit message, including who(), path1(), // path2(), and message reported by O/S (which is // subject to locale on some O/S's. int native_error() const; // a return of 0 implies a library (rather than system) error error_code error() const; // filesystem defined error code const std::string & who() const; // name of func throwing exception const path & path1() const; // argument 1 to func; may be empty() const path & path2() const; // argument 2 to func; may be empty() That's pretty heavyweight, but each function has important uses. For Boost.Threads, path1() and path2() obviously don't apply, but I wouldn't be surprised if a string identifying the thread in some way wasn't a possible need. --Beman __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk