2

Let's say I have a methodA that raises an exception:

def methodA(x, y):
     if y != 0: 
         z = x / y
         return z
     else:
         raise ZeroDivisionError("zero can not be a denominator")

And in methodB I called methodA without handling the exception:

def methodB(x, y):
     print methodA(x, y)

Here I want something that could warn me there is a potential risk of ZeroDivisionError in methodB, and that it's better to catch it. Is there any way to add some certain codes in methodA, or can we use some tool to find that I ignored some important exceptions?

Fan
  • 23
  • 3
  • 2
    I doubt it - how would the static analysis know whether you deliberately are letting the exception percolate up to somewhere more sensible to catch it (which may not be in your code at all, remember!) or have just forgotten to deal with it? It's helpful for the documentation for `methodA` to note that it can `raise ZeroDivisionError`, but otherwise it's up to the consumer to handle as they see fit. – jonrsharpe May 12 '15 at 13:30
  • 1
    Or, a third option, whether you've *already dealt with it*, e.g. by checking `y > 0` in `methodB` (or wherever it's called from)? – jonrsharpe May 12 '15 at 13:44
  • 1
    Nitpick: `y` is the denominator here, but the exception refers to it as the numerator. – Colonel Thirty Two May 12 '15 at 14:57

1 Answers1

5

I'm not aware of anything close to such a mechanism in Python, but in general methodA should not care about if methodB deals with the exception or not. At each level (such as methodB) only exceptions that methodB could deal with (at some documented/specified level) should be caught. If methodB can not deal with for example ZeroDivisionError then perhaps nobody can (and then not catching it is the correct hing to do), or, it could be that in some call graph, methodC will catch it and do what is correct in context of methodC.

Also note the somewhat related (but reverse) question for Java: Java: checked vs unchecked exception explanation

and for C++ https://softwareengineering.stackexchange.com/questions/114338/why-are-exception-specifications-bad and Should I use an exception specifier in C++?

Community
  • 1
  • 1
Johan Lundberg
  • 26,184
  • 12
  • 71
  • 97
  • "in general `methodA` should not care about if `methodB` deals with the exception or not" --- I'd go one step further: By raising an exception, `methodA` is _explicitly_ stating that it can not or will not deal with the situation. Not only does `methodA` not care if the exception is ever handled, it has completely given up on the whole program, and is intentionally crashing it. – Kevin J. Chase May 12 '15 at 14:26
  • "it has completely given up on the whole program, and is intentionally crashing it". No, that is not true at all. If it had given up on the whole program it would not need to be exception safe. Exception safe code use exceptions to tell that it could not do its part. Exceptions are in such case always *possibly recoverable*, completely depending on the callers. – Johan Lundberg May 12 '15 at 14:42
  • Exceptions _always_ crash the program. Even a comparatively innocent `StopIteration` will crash a Python program if it's not caught and handled. The only... er... exception is when some other code higher up the call stack (which presumably knows better) dives to the rescue. Since the exception-raising code _can not know_ if a given exception will or will not be caught, a `raise` command must always be considered intentionally crashing the program, since that's the most likely outcome. If the program somehow survives, that is a (hopefully pleasant) surprise. – Kevin J. Chase May 12 '15 at 15:10
  • Again I don't agree but let's leave this. – Johan Lundberg May 12 '15 at 17:56
  • Agreed --- this is is a tangent. – Kevin J. Chase May 12 '15 at 19:43