Reporting important unhandled exceptions before they occur

[Peter Hansen]

Afanasiy wrote:
> 
> On Tue, 04 Nov 2003 10:55:29 -0500, Peter Hansen <peter at engcorp.com>
> wrote:
> 
> >Afanasiy wrote:
> >>
> >> 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?  ;-)
> 
> 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