those darn exceptions

[Chris Torek]

>Chris Torek wrote:
>> I can then check the now-valid
>> pid via os.kill().  However, it turns out that one form of "trash"
>> is a pid that does not fit within sys.maxint.  This was a surprise
>> that turned up only in testing, and even then, only because I
>> happened to try a ridiculously large value as one of my test cases.

In article <96itucFadiU1 at mid.individual.net>
Gregory Ewing  <greg.ewing at canterbury.ac.nz> wrote:
>It appears that this situation is not unique to os.kill(),
>for example,
>
> >>> import os
> >>> os.read(999999999999999999999999, 42)
>Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>OverflowError: Python int too large to convert to C long
>
>In fact I'd expect it to happen any time you pass a
>very large int to something that's wrapping a C function.
>
>You can't really blame the wrappers for this -- it's not
>reasonable to expect all of them to catch out-of-range ints
>and do whatever the underlying function would have done if
>it were given an invalid argument.
>
>I think the lesson to take from this is that you should
>probably add OverflowError to the list of things to catch
>whenever you're calling a function with input that's not
>fully validated.

Indeed.  (Provided that your call is the point at which the validation
should occur -- otherwise, let the exception flow upwards as usual.)

But again, this is why I would like to have the ability to use some
sort of automated tool, where one can point at any given line of
code and ask: "what exceptions do you, my faithful tool, believe
can be raised as a consequence of this line of code?"

If you point it at the call to main():

    if __name__ == '__main__':
        main()

then you are likely to get a useless answer ("why, any exception
at all"); but if you point it at a call to os.read(), then you get
one that is useful -- and tells you (or me) about the OverflowError.
If you point it at a call to len(x), then the tool tells you what
it knows about type(x) and x.__len__.  (This last may well be
"nothing": some tools have only limited application.  However, if
the call to len(x) is preceded by an "assert isinstance(x,
(some,fixed,set,of,types)) for instance, or if all calls to the
function that in turn calls len(x) are visible and the type of x
can be proven, the tool might tell you something useful agin.)

It is clear at this point that a simple list (or tuple) of "possible
exceptions" is insufficient -- the tool has to learn, somehow, that
len() raises TypeError itself, but also raises whatever x.__len__
raises (where x is the parameter to len()).  If I ever get around
to attempting this in pylint (in my Copious Spare Time no doubt
:-) ), I will have to start with an external mapping from "built
in function F" to "exceptions that F raises" and figure out an
appropriate format for the table's entries.  That is about half
the point of this discussion (to provoke thought about how one
might express this); the other half is to note that the documentation
could probably be improved (as someone else already noted elsethread).

Note that, if nothing else, the tool -- even in limited form,
without the kind of type inference that pylint attempts -- gives
you the ability to automate part of the documentation process.
-- 
In-Real-Life: Chris Torek, Wind River Systems
Intel require I note that my opinions are not those of WRS or Intel
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W)  +1 801 277 2603
email: gmail (figure it out)      http://web.torek.net/torek/index.html