[Q] Are Exceptions used that much in practice?

[David Bolen]

Greg Ewing <greg at cosc.canterbury.ac.nz> writes:

> A minor gripe here - it would be more useful if Python
> had some subclasses of IOError to distinguish between
> different reasons for failure, so you can catch them
> more selectively. If the reason is "the file doesn't
> exist", you might want to do something to make it exist
> and then try again. But if the reason is "the file exists
> but the user doesn't have permission" or "someone put 
> peanut butter in the disk drive", you probably just want 
> to let the exception propagate.

I suppose one of the issues is constructing a reasonable class
hierarchy that would portably represent the common failure mores.

It's not necessarily portable, but even if you can't distinguish at
the exception level, there's nothing stopping the exception handling
code from examining the associated object with the exception, and if
the code doesn't match the case it wants to handle, just using "raise"
to re-raise the same exception and let it continue propagating.

In the case of IOError that does imply parsing a string and assuming
it starts with [Errno #], which is sort of crufty.  But other
exceptions (such as those from win32all) are fairly standardized as a
tuple with the code as the first element - something I also tend to do
with my own user exceptions in my code.

Thus, you can get a reasonable mix in terms of design between the
exception class hierarchy and then the finer grained specific failure
within a class of exceptions.

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/