Exception handling wart in Python

[Leo Lipelis]

On Thu, 01 Nov 2001 19:35:46 -0500, Leo Lipelis wrote:

> Hi Pythoneers,
[snip]

Thanks to all who replied to my posts.  As a result of this, I hope that I
was able to highlight an important (at least to me) weakness in the way
exceptions are treated in Python.

I have, in turn, learned a few things as well.  For one, the generic
nature of Python functions makes tracing exceptions more difficult (but
not impossible).  Another thing I have realized, is that in Java the
process of tracing exceptions is made much easier by the fact that you
either have to catch it, or declare it in "throws" statement.  That means
Java compiler doesn't have to search deep.  I think this difficulty is
much more significant than the generic nature of Python's functions,
because it would force the exception checker to trace deeply, and thus
would become time and memory consuming.

Going back to generic nature of Python's functions, I think, obviously,
most of the functions in real Python programs are not generic at all, even
though from the point of view of Python compiler, they are generic. But
from a higher level point of view, they're not generic.  It's possible to
use some heuristics or assumptions to distinguish generics from
non-generics.  One heuristic that could be attempted is to cound all the
methods used by all class objects, and then determine the 5-10% of the
most often used methods.  For example, many objects have __str__ method,
and so on.  This way you can determine (in a fuzzy way) all the methods
that are applicable for generic programming.  Obviously it's not perfect,
but it's better than nothing, and it might actually work quite well.

Another thing is to assume that all class object methods are non-generic
and all module methods are generic.  This is a bit artificial and would
force the programmer who wants to use exception checker to put more
methods in classes.

Yet another thing that could be done is to not guarantee the same results
for one function, but rather make the results depend on how it's used.
Since this tool is only a *warning* tool and since it's not meant to force
anything, no harm is done.  That way, a generic function will get
different warnings depending on how it's used.  Because the exception
handling is not *forced*, this can work *very well*.  Then, the exception
checker tool could get some hints to turn off warnings for some functions
that are generic and that are library functions used in many places.
Another thing that could also be done is not to generate any warnings for
any library functions, including standard Python libs and everything in
site-packages.

Thanks again to everyone.  I now consider this thread closed to myself. If
you want to discuss further, please note that I won't be reading it and I
won't be able to reply.