1

I recently asked a question on SO where I was trying to understand how to catch an exception in a piece of code which runs indefinitely. I was initially expecting that

try:
    the_code_which_runs_indefinitely_and_which_raises_an_exception()
except:
    print('the exception in the code which runs indefinitely was caught')

would work (the actual Python code is in the linked question - I am asking on SE because I want to understand the reason of the choice in the implementation rather than a solution (though if there would be one for my specific problem it would be great as well)).

It does not. As mentioned in the question, my wild guess is that the try/except construction is not in place yet (and will never be) while the_code_which_runs_indefinitely_and_which_raises_an_exception() runs.

What are the design reasons behind the decision to have exceptions which cannot be intercepted (when the catching mechanism is well in place, and in the case of Python even encouraged)?

Improve this question

2 Answers 2

Reset to default
4

In Python, exceptions are not only used for errors, but also for more general control flow. The not-error exceptions should not be caught accidentally. Therefore a blank except: clause only catches Exception subclasses, not all BaseException subclasses. You can still catch these exceptions explicitly.

The Python documentation lists the following non-error exceptions (Python 2), (Python 3.6):

  • SystemExit, which is raised by sys.exit().
  • KeyboardInterrupt, which corresponds to Ctrl-C / the SIGINT signal.
  • GeneratorExit, which is raised when a generator or coroutine is closed.
  • … (there may be additional user-defined exceptions)

Since these are exceptions, finally: clauses and with: context handlers can run as expected.

This is unrelated to the problem in your SO question: error handling in event loops is more tricky than just catching an exception because there's no linear control flow and call stack. If an error occurs on another thread, you will obviously not be able to catch it.

Improve this answer
1
  • I know about the implications of using bare except: to catch exceptions - here I just wanted to use some pseudocode to build the question (rather than going into pure Python specifics). The second part of your answer is particularly useful - it drags my thinking into the right direction. Thanks! (the first one was too :))
    – WoJ
    Sep 5, 2017 at 10:21
2

What are the design reasons behind the decision to have exceptions which cannot be intercepted

There are exceptions that tell you that the system as a whole is no longer stable - exceptions that you can't don't anything about. What can you do if the OS tells you it is out of memory? Keep carrying on without enough storage? What if your process has overflown the stack? It means the memory you are using can no longer be trusted. What do you do?

For such exceptions, the best thing to do is shut down the process, trying to ensure no damage (or no more damage) can be caused to the user data.

Improve this answer
3
  • 1
    I know and understand this explanation, but it's always seemed insufficient to me. Yes, a computer can detect that it's no longer able to guarantee its own commitments, but that doesn't always mean that terminating the process is the right thing to do. What if I've been mining currency for hours? What if the process is guiding atmospheric re-entry and the alternative to continuing is certain loss of control? I can think of endless possibilities where I'd want best-effort soldiering-on rather than giving up.
    – Kilian Foth
    Sep 5, 2017 at 10:24
  • 1
    @KilianFoth - in those conditions, you don't use a language/paradigm like this.
    – Oded
    Sep 5, 2017 at 10:25
  • @KilianFoth Systems this important have failsafes which work should nothing else work. In a plane the pilot can always override the computer. If you are mining currency, progress is saved to a hard disk that doesn't lose data when the power goes off. That said, in Java, you can actually catch Throwables which are generally considered to be exceptions that you generally do not want to catch. Though you could, in theory, do so if for no other reason then make a last ditch chance at recovering memory or whatnot.
    – Neil
    Sep 5, 2017 at 11:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.