Re: Boost.Threads draft library submission

From: williamkempf_at_[hidden]
Date: 2001-03-15 13:18:39

--- In boost_at_y..., "E. Karpachov" <jk_at_s...> wrote:
> On Thu, Mar 15, 2001 at 05:01:06PM -0000, williamkempf_at_h... wrote:
> > I will *NOT* throw an exception containing an errno value.  Such 
a 
> > value is not portable (the errnos returned by various thread APIs 
> 
> (By the way, it is portable as far as POSIX is - but I can 
understand that
> POSIX portability is not sufficient.)

Exactly.

> > will not match) and so will not be useful to programmers.  If the 
> > specific type of error that occurred is necessary (I'm not sure 
it is 
> > in most cases) then we either need to define our own errnos, or 
> > preferrably throw different exceptions (or at least change the 
what() 
> > text accordingly).
> 
> Yes, but you could at least incapsulate POSIX errno or some other
> system-dependent error information deep inside of exception class, 
in
> separate implementation-defined part. Something like
> 
> class base_thread_error : public std::runtime_error { // or 
something
> public:
>         // ...
>         virtual const char *what() const;
>         impl_errno *error_code() const;
> private:
>         struct impl_errno *error_code_;
>         // ...
> };

You miss the problem here.  Yes, I could expose an errno that 
implementation specific here.  But it's pointless in a portable 
sense, since it IS implementation specific.  Client code can not make 
use of the errno in a portable manner.  If the specific errno is 
useful to know (debatable in this context) than it must be translated 
into a portable bit of information.  I will *NOT* expose 
implementation specific errnos on the interface here.  Portable ones, 
maybe.

Bill Kempf