26

For a block like this:

try:
    #some stuff
except Exception:
    pass

pylint raises warning W0703 'Catch "Exception"'. Why?

yanchenko
  • 56,576
  • 33
  • 147
  • 165

6 Answers6

37

It's considered good practice to not normally catch the root Exception object, instead of catching more specific ones - for example IOException.

Consider if an out of memory exception occurred - simply using "pass" isn't going to leave your programme in a good state.

Pretty much the only time you should catch Exception is at the top level of your programme, where you can (try to) log it, display an error, and exit as gracefully as you can.

Roland Coeurjoly
  • 47
  • 2
  • 6
Greg
  • 316,276
  • 54
  • 369
  • 333
  • 3
    this bad habit will also generate considerable debugging nightmares. Especially when other exceptions than those you have thought of are raised inside your try/except. And this simply happens... – vaab Nov 29 '11 at 13:51
  • 17
    if you really want to use that catch, you can disable pylint warning using following construction: `except Exception: # pylint: disable=broad-except` – Dmitry P. Feb 17 '20 at 02:50
20

It's good practice to catch only a very narrow range of types. 'Exception' is too general - you will end up catching not just the errors you planned for, but other errors too, which may mask bugs in your code that would be quicker to diagnose if they weren't caught at all, or possibly would be better dealt with by a single very high level exception handler.

Having said that, since Python2.6, catching Exception has become a lot more reasonable, because all the exceptions that you wouldn't want to catch (SystemExit, KeyboardInterrupt) no longer inherit from Exception. They instead inherit from a common BaseException instead. This has been done deliberately in order to make catching Exception relatively harmless, since it is such a common idiom.

See PEP 3110 for details & future plans.

Jonathan Hartley
  • 15,462
  • 9
  • 79
  • 80
4

because it thinks that you're catching too much. and it's right.

SilentGhost
  • 307,395
  • 66
  • 306
  • 293
  • 6
    Actually, this is usually true, but not always. Consider a REST API - if you don't catch everything you can at the top-level, then one small bug in one small part of your API could knock over your entire API for all users. – dstromberg May 28 '20 at 20:42
1

like Greg's answer, 'Exception' is a base class and exceptions should be derived from this class, see also exceptions.Exception.

Here a very usefull list of Errors in pydocs

Note also the very handy traceback module which allows you to find out where the exception occured. Using only 'except: ...' will show you what Error you should best use in your case. For example, try this code (toggle the comment), perhaps you'll accept it:

import traceback
#absent = 'nothing'
try:
    something = absent
except  NameError:
    traceback.print_exc()
else:
    print("you get here only when you uncomment 'absent'")
Remi
  • 20,619
  • 8
  • 57
  • 41
1

Exception are raised when something... exceptional occurs. It's generally a good thing that the program terminates.

You may want to ignore some exceptions, but IMO there's no good reason for catching a base-class like that.

Bastien Léonard
  • 60,478
  • 20
  • 78
  • 95
  • 12
    Hey. I don't think I agree that 'there is no good reason' - I can imagine, for example, a GUI program that raises an exception when attempting a particular operation on a particularly tricky data set. It's all well and good as a programmer to say that an unexpected exception should end the program with a stack trace (fail early), but in practice what the user wants is for the current operation to fail gracefully, maybe with a messagebox or logfile message, and then for the GUI to continue operating so that they can e.g. save their data before anything else bad happens. – Jonathan Hartley Dec 24 '09 at 18:04
  • 1
    I totally agree, I was refering to the way the OP ignores exceptions with `pass`. I should have made my point more clear. – Bastien Léonard Dec 25 '09 at 16:37
  • Beg your pardon, fair enough then. – Jonathan Hartley Dec 30 '09 at 16:11
-1

Catching Exception (without re-raising) has 2 really bad side effects: errors get eaten, so you lose the stack trace, but also that ctrl-c (or whatever the break key is on your operating system) also gets handled here.

The typical behavior of programs like this is that either they can't be stopped, or that ctrl-c causes the control flow to skip forward (to the exception handler), and then continue. Then either the code can't be interrupted, or you need to hammer on ctrl-c to get it to stop.