Date: 2001-03-16 09:29:47
--- In boost_at_y..., "David Abrahams" <abrahams_at_m...> wrote:
> I think you might want to reconsider. It would of course be nice if
> generalize our thread exceptions and cover all possibilities so
> didn't have to deliver platform-specific error codes, but it seems
> that platforms will probably not be reporting the same kinds of
> some point, users will need to know the real reasons for a threading
> failure, and may need to respond to the failure in platform-
I appreciate this. Let me elaborate on my stance first, and then we
can decide which is the better course.
1) Most errors that occur in threading code arise from misuse of the
APIs. Being wrapped in a higher level API it is likely that most of
these errors either will not occur or will be caught in the higher
level before ever occuring.
2) A majority of the errors that are left are very generic sorts of
errors. Failures to allocate resources and the like. These should
be trivial to translate to a platform neutral exception type(s).
3) The few that are left are likely to be exotic errors that are
highly unlikely to occur. As such, short of reporting that an error
occurred there's probably not much that even platform specific code
can do with the error code here any way. So translation to an error
string is probably enough, and it's likely that most
platforms/libraries will have the facilities to do this.
4) When the error code might truly be useful is during debugging.
However, at this time a debugger will allow you to ascertain the
platform specific error any way.
So, though it means more work for the library developer, I think it's
better to not expose the platform specific error codes. Just for a
real world example to illustrate that others feel the same way... the
pthread API is often a wrapper around native thread support and it
returns pthread's specific error codes and not platform error codes.
This allows programmers to write portable code, while returning
platform specific codes will not.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk