Re: [boost] Re: Boost.Threads draft library submission

From: David Abrahams (abrahams_at_[hidden])
Date: 2001-03-16 19:34:04

Your arguments are good ones. All I want to hear from you to be satisfied is
that you've analyzed the threading domain carefully enough to know that the
arguments apply there (and it sounds like you have).

-Dave

----- Original Message -----
From: <williamkempf_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, March 16, 2001 9:29 AM
Subject: [boost] Re: Boost.Threads draft library submission

> --- 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
>
>
> List-Unsubscribe: <mailto:boost-unsubscribe_at_[hidden]>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>