[Xapian-devel] Re: [Xapian-commits] 7990: trunk/xapian-core/trunk/xapian-core/bin/ trunk/xapian-core/tests/harness/

[Olly Betts]

On Fri, Mar 30, 2007 at 05:33:49PM +0100, Richard Boulton wrote:
> Olly Betts wrote:
> >Looking at the winsock.h header in mingw, the "WSA" error codes are all
> >at least 10000.  So it would be easy enough to decode real errno values
> >with strerror() while handling the other values with something else.
> >
> >If you're talking about sticking error codes which collide with errno
> >values in the "errno" field of Xapian::Error objects, that way madness
> >surely lies!  Catchers of Xapian::Error (not unreasonably) expect to be
> >able to decode the errno field with strerror().  And strerror() would
> >give an entirely irrelevant message if we start sticking other integer
> >error codes there with overlapping ranges.
> 
> Certainly, overlapping ranges would be a mistake...  I assumed that all 
> WSA error codes were non-overlapping with errno codes, but if this isn't 
> the case I think the best approach would be as Olly suggests to check 
> for values less than 10000 returned by socket_errno() and just append 
> the formatted message to the error message held in the exception for 
> these (I think messing around with translating error codes would just be 
> a painful waste of time).

As far as I can tell they're non-overlapping, though Mark seemed to be
expressing some doubt.

But I think it's a mistake to stick a number in a slot described as
errno, and then have to hack around generic code because strerror()
doesn't decode it (apparently Microsoft's strerror() gives a generic
error for an unknown errno value rather than including the number in the
error message like glibc does...)

> Would it be a good idea, though, to add a method to the base 
> Xapian::Error class which decoded error codes, and returned a string. 
> On unix platforms, this would just be a wrapper around strerror(), but 
> on windows it could call whatever is appropriate (and not have to worry 
> about freeing memory).  The codes must still be unique, though.

I'm not sure that's worth the effort - making a numeric errno value
available has some arguable use, as clients can easily test it against
EWHATEVER.  However, in isolation from the function call which resulted
in that errno value, it's much less useful and I don't believe I've ever
seen it tested.  It's even less useful if you need to start testing
random platform-specific values to get portable code.

So perhaps the right answer is to make errno private and just decode it
and add it to the error message on the fly (or perhaps better when the
error class is constructed).

Cheers,
    Olly