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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
