Re: Boost.Threads draft library submission

From: williamkempf_at_[hidden]
Date: 2001-03-16 09:29:47

--- In boost_at_y..., "David Abrahams" <abrahams_at_m...> wrote:
> Bill,
> 
> I think you might want to reconsider. It would of course be nice if 
we could
> generalize our thread exceptions and cover all possibilities so 
that we
> didn't have to deliver platform-specific error codes, but it seems 
to me
> that platforms will probably not be reporting the same kinds of 
errors. At
> some point, users will need to know the real reasons for a threading
> failure, and may need to respond to the failure in platform-
specific ways.
> 
> -Dave

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.

Bill Kempf