> From: Martin Brown <[EMAIL PROTECTED]> > > Hi, > > Regarding the OS error code / exception type debate; I > may have missed something here, so apologies if I > have. Speaking as a user of your wonderful > libraries: > > 1. I need all the data available - the error may be > happening on a computer in Japan and the data may be > filtered through many layers of sales and support.
All of what data? Full stack traces and memory dumps for instance? Do you think it's reasonable for a library to provide this much data, or is it the responsibility of the application? What's the minimal amount of information that you think must be provided by the library? > 2. The user needs a localised error message. Is the textual representation of the exception name enough? If not, how do you propose a library provide such a localised error message? > 3. Most errors are for the user to deal with. Many > problems are simply due to configuration (e.g. > permissions) or interaction with other software (e.g. > virus scanners). Auto-recovery is often only > possible to a limited extent. > > 4. Exception object types are useful for > auto-recovery, but are less important when generating > a message for a user. Interesting view point. > (1) implies that the error reporting system cannot > destroy any information (e.g. representing many error > codes in a single exception object with no way to get > at the original code). What I'm not convinced about here is the fact that error codes are system dependant. More importantly, most of them can be accessed by calling a system specific function or other mechanism (errno and GetLastError are examples). (OK, these mechanisms are a little fragile since the "last error" can be changed if intermediate exception handlers called methods which also set the errno... but such exception handlers *could* be made to not do this.) So with out a "standard" mechanism for reporting error messages, I'm not sure that carrying a non-portable error code is truly beneficial. And with a "standard" error reporting mechanism it may be that what() alone would meet all usage requirements. I think finding a solution to this problem would be nice, but I'm not about to be the one to tackle it, and it would be a seperate library any way. So I'm left with a lot of vague "wishes" that I can't meet alone, and no concrete consensus of what a "minimal" solution should be. > (2) & (3) imply that OS error codes must be available > for generating a message using the OS facilities. It > is pointless having a boost set of error codes, as > this would require boost writing and maintaining > localised error messages. But there will be non-OS errors that have to be reported as well. How do you intend to deal with both types? > (4) implies that I still want exception types so I can > recover when possible, but there must be a way of > getting the OS error code. What if there's not an OS error code? William E. Kempf [EMAIL PROTECTED] _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
