I have an idea I think would be useful, although exactly how useful I
am not sure, and just how to implement it is an even bigger question.

Suppose that we had a way of finding which exceptions are
(potentially) raised by all the built-in Python functions.  (For now,
this would have to be read from a file, or built in to pylint / astng,
or something like that, which is not a very nice way to get started,
but so it goes.)

Now, if I write a function:

    def ham(arg1, arg2):
        return arg1 + arg2

then a call to ham() can raise whatever exceptions are raised by the
__add__ and/or __radd__ operators for the two argument types.  So:

    ham('eggs', spam)

will potentially raise a TypeError, depending on the type of spam: if
it's a string, the add works, if it's an int, I get a TypeError, and
so on.  Similarly:

    class SillyError(Exception):
        pass
    class Silly(object):
        def __init__(self, value):
            self.value = value
         def __add__(self, other):
            raise SillyError()

    ham(Silly(1), 2)

will (always) raise SillyError.

In general, then, the exceptions associated with any given line depend
on what function(s) are called there and the type(s) of the
parameter(s) delivered.  (Or, for a "raise" statement, the exception
for that statement is the type of the argument to raise.)
Type-tracking and inference is, of course, exactly what pylint does.

It just needs to do it a little more and/or differently to be able to
report on exceptions.

If pylint could get "possible exceptions" for each statement, it could
give you a reports on try/except sequences about which exception(s)
might occur that you are not catching, or which exception(s) you are
catching that cannot occur.  It should also be able to propagate the
uncaught exception information upwards, the way pylint and astng do
with return values, so that:

    eggs = ham()
    eggs.fry()

reports a problem if eggs does not have a .fry().

One reason I am not sure how useful this is, is that the set of
possible exceptions in a lot of code will be huge: in some line that
calls a(arg), if a() calls b() and b() calls c() and c() calls d() and
so on, the possible exceptions at a(arg) could be "TypeError, OSError,
ValueError, KeyError, ..." (basically almost everything).
Exception-tracking would perhaps only be useful in the lowest-level
service functions that only make a few calls.

Chris
_______________________________________________
Python-Projects mailing list
[email protected]
http://lists.logilab.org/mailman/listinfo/python-projects

Reply via email to