##// END OF EJS Templates
Swallow potential exceptions from showtraceback() (#13934)...
Swallow potential exceptions from showtraceback() (#13934) The nbgrader project is aware of a form of cheating where students disrupt `InteractiveShell.showtraceback` in hopes of hiding exceptions to avoid losing points. They have implemented a solution to prevent this cheating from working on the client side, and have some tests to demonstrate this technique: https://github.com/jupyter/nbgrader/blob/main/nbgrader/tests/apps/files/submitted-cheat-attempt.ipynb https://github.com/jupyter/nbgrader/blob/main/nbgrader/tests/apps/files/submitted-cheat-attempt-alternative.ipynb In essence, these attacks import the interactive shell and erase the traceback handler so that their failing tests won't report failures. ```python import IPython.core.interactiveshell IPython.core.interactiveshell.InteractiveShell.showtraceback = None ``` The problem is that this causes an exception inside the kernel, leading to a stalled execution. The kernel has stopped working, but the client continues to wait for messages. So far, nbgrader's solution to this is to require a timeout value so the client can eventually decide it is done. This prevents allowing a value of `None` for `Execute.timeout` because this would cause a test case to infinitely hang. This commit addresses the problem by making `InteractiveShell._run_cell` a little more protective around it's call to `showtraceback()`. There is already a try/except block around running the cell. This commit adds a finally clause so that the method will _always_ return an `ExecutionResult`, even if a new exception is thrown within the except clause. For the record, the exception thrown is: TypeError: 'NoneType' object is not callable Accepting this change will allow nbgrader to update `nbgrader.preprocessors.Execute` to support a type of `Integer(allow_none=True)` as the parent `NotebookClient` intended. Discussion about this is ongoing in jupyter/nbgrader#1690.
Matthias Bussonnier -
r28101:e548ee23 merge
Show More

Documenting What's New

When making a new pull request that either adds a new feature, or makes a
backwards-incompatible change to IPython, please add a new .rst file in this
directory documenting this change as a part of your Pull Request.

This will allow multiple Pull Requests to do the same without conflicting with
one another. Periodically, IPython developers with commit rights will run a
script and populate development.rst
with the contents of this directory, and clean it up.

Files which describe new features can have any name, such as
antigravity-feature.rst, whereas backwards incompatible changes must have
have a filename starting with incompat-, such as
incompat-switching-to-perl.rst. Our "What's new" files always have two
sections, and this prefix scheme will make sure that the backwards incompatible
changes get routed to their proper section.

To merge these files into :file:whatsnew/development.rst, run the script :file:tools/update_whatsnew.py.