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).
----- Original Message -----
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/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk