Reporting important unhandled exceptions before they occur

[Afanasiy]

I recently decided it would be best for me to know about unhandled
exceptions before they occur. I imagined some tool could check for this,
possibly even an extreme mode of PyChecker. However, I found none.

I suppose, without much thought, that some tool could just list the last
few levels in which an exception could be thrown but is not handled.

Does such a tool exist?

P.S. I do not need to be lectured on why you might think this is bad.

 

[Peter Hansen]

I recently decided it would be best for me to know about unhandled
exceptions before they occur. I imagined some tool could check for this,
possibly even an extreme mode of PyChecker. However, I found none.

I suppose, without much thought, that some tool could just list the last
few levels in which an exception could be thrown but is not handled.

Does such a tool exist?

P.S. I do not need to be lectured on why you might think this is bad.

How about being lectured on why it's practically impossible for the
general case? ;-)

(That is, given that Python is so dynamic, effectively any code called
can generate any one of a whole variety of errors, and static analysis
may be unable to tell you anything useful about it. For example, an
exec statement can presumably raise any exception at all... )

If you can narrow down the scope of the problem, you might find a
solution, but to me it sounds like taking an idea from Java (where
everything has an explicitly defined set of possible exceptions)
and trying to apply it to an area where it just can't work.

-Peter

 

[Afanasiy]

How about being lectured on why it's practically impossible for the
general case? ;-)

Then I am willing to accept the true general case, that which myself
as a human can generally determine by looking at the code and explicitly
seeing the few exceptions a function might throw.

I always assumed I would accept caveats, as I do when using PyChecker or
Psyco. I do not mean to report exceptions thrown from eval or related.

I believe there exists a subset of the apparent infinite possibilities
which can be reported and which would be utterly useful. ;-)

 

[Peter Hansen]

Then I am willing to accept the true general case, that which myself
as a human can generally determine by looking at the code and explicitly
seeing the few exceptions a function might throw.

I always assumed I would accept caveats, as I do when using PyChecker or
Psyco. I do not mean to report exceptions thrown from eval or related.

I believe there exists a subset of the apparent infinite possibilities
which can be reported and which would be utterly useful. ;-)

Okay, that's a start.

What about NameError when thrown by code that accesses names that don't
exist at the time they are executed (e.g. an undefined global)?

And AttributeError for just about any other case where you have an
instance or class or something and try to reference an undefined
attribute? (And what, then, do you do with the magic __getattr__
etc?)

Okay, maybe you're willing to exclude *all* such cases, which
I suspect leaves you with only a few leftovers, which you might
consider useful:

1. Exceptions explicitly thrown by various C extensions.

2. Any exceptions in Python code where there is an explicit "raise"
statement (and, presumably, the class/instance being raised is
not determined dynamically, as it could be in special cases).

Are there any other useful cases left?

(Note, I'm not criticizing the idea, just helping explore whether
there's enough possible utility to make it worthwhile.)

This would then reduce to scanning code statically (after all,
we'd better exclude almost all dynamic features since they simply
open up the possibility of *any* exception, even new dynamically
constructed Exception subclasses, being raised).

You look for all "raise" statements of the trivial form
(e.g. "raise Class" or "raise Class()", with optional arguments)
and then for every routine which explicitly calls the raising
routine, you check whether it has "except" handlers that cover
the specified case.

Could be of moderate use in many kinds of code. And I can't
see why it wouldn't be feasible to add this to PyChecker, since
it's right up its alley...

-Peter