|
Boost : |
From: William E. Kempf (wekempf_at_[hidden])
Date: 2003-01-10 12:18:37
> From: David Abrahams <dave_at_[hidden]>
> What information do you *have* at the point of detection?
Depends on numerous factors, such as the platform it's running on and how much time you want to spend gathering information. We could provide a stack trace, a memory dump, a listing of running processes, the OS name and version, and on and on.
This may sound facetious, but I'm frustrated asking the same question over and over again, and think this illustrates what I've been saying all along. To restate the question one more time: "What's the minimal amount of information that would be useful and portable?" Most of the above doesn't fit that billing... and I'm not sure that an error code does either. An error code is not portable. A non-portable error code seems to be of not much use, for the following reasons:
* There will be errors that occur which do not occur from calls to system services. Mapping these to system error codes is not something you can easily do in a portable fashion, and may not be possible in any event. Adding non-system specific error codes is problematic, since the values of system error codes are system specific, generally not known, and may overlap between systems.
* Most people are saying they prefer different exception types over an "uber-exception" that has to be interrogated for the cause in the exception handler. I tend to agree with this. If you have seperate exceptions for each type of error that can occur then there seems to be no reason to carry an error code any way. The what() method should suffice as a portable mechanism here.
William E. Kempf
wekempf_at_[hidden]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk