[py-dev] revising exception handling / help appreciated

[holger krekel]

On Sun, Jan 02, 2005 at 16:22 +0100, Laura Creighton wrote:
>     try:
>         do_something_with(path)
>     except py.error.NotFound: #ENOENT
>        ...
>     except py.error.PermissionDenied: #EPERM
>        ...
> >OTOH, it's harder to guess the exact meaning of these "nice" names. 
> >It at least causes thinking and documentation effort. Whereas
> >with "errno-classes" we can say: google luckily, since these weird 
> >abbreviations are easily found as the first hit.  Note e.g. that 
> >PermissionDenied may mean either "EACCES" or "EPERM", see e.g. 
> >http://www.wlug.org.nz/EPERM for the difference.  
> 
> The place we need to spend the effort is on the error message that is seen
> when the user has an error.

Well, the py lib targets developers and programmers 
and they/we should be able to reference error conditions in 
a consistent, reliable and exact way.  This is not neccessarily 
related to what a user will or should see. 

Also I've done the current error-conversion hacks and i can
tell you they may appear simple but they are full of
ambivalence and hard to get right, if "right" can even 
be defined unambigously.   They are also not complete, i.e. 
some errors will just propagate in raw form, i.e. IOError, OSErrors. 
This is all messy and i'd rather not try to put more effort 
there but go for a simpler and deterministic scheme, reusing 
common standard error definitions.

POSIX error specifications have such a clear definition and
they can be looked up easily. Also the underlying modules
(socket, os, file-IO, etc.pp) do the hard work of preserving
Errno's and the 'errno' module provides the mapping to the
google-able names.   

> If they all look like this:
> 
> http://docs.python.org/lib/module-errno.html
> 
> then using Google will be mandatory for figuring out what your program isn't
> doing.  I'd rather save our users this time.

it's a shallow and deterministic learning curve and many
programmers can just reuse their existing knowledge.  The
third time you encounter e.g. "EPERM: /etc/passwd" or "ENOENT:
/etc/asldkajsdlkasjdl" you will probably not have to google
for it anymore. 

cheers, 

    holger