nbconvert: "allow errors" vs. "raises exception"

Support for the raises-exception tag was implemented in #684.

However, if a cell tagged with raises-exception does not raise an exception, nothing bad seems to happen.

I would expect an exception to be raised in this case, probably a CellExecutionError.

If this behavior is not wanted, the tag should be renamed to something like allow-exception.

Alternatively, there could be a configuration setting to switch between the two behaviors, but the default should nevertheless be changed.

Of course, the global “allow errors” setting should still allow the error of not raising an exception.

UPDATE:

Related issues:

About this issue

Original URL
State: closed
Created 6 years ago
Comments: 17 (16 by maintainers)

Most upvoted comments

If this is ever reconsidered, I would also propose that cells marked with raises-exception which don’t raise one should crash with something like a DidntRaise exception. pytest does the same when using the pytest.raises context manager in a test and I find that very helpful. I would also like this behaviour in notebooks.

Maybe it would help to clearly separate the different expectations about the behaviour by having two flags:

raises-exception => must raise an exception
might-raise-exception => might or might not raise an exception

obestwalter on Nov 20, 2019

it would be damaging to change behavior at this time.

I think the long-term damage caused by the unexpected behavior of raises-exception will be greater than the (probably non-existent) short-time damage of changing said behavior.

If anything breaks, it will break loudly, which is a good thing!

If we keep the current behavior, the problems will be much harder to locate and much more subtle and annoying (and therefore damaging).

mgeier on Apr 23, 2019

I actually see making a pattern available for exceptions MUST be raised as a clear anti-pattern to modern programming paradigms.

I don’t understand what you want to say with this.

We are not discussing whether Python (or any language) should have exceptions or whether exceptions should be used only for error reporting or for control flow as well. Right?

If you have a code cell that raises an exception in your Jupyter notebook and you actually want that to happen (for whatever reason, whether you use modern programming paradigms or not), you also expect an exception to happen. And if it does not happen, you want to be made aware of it, right?

Can you please tell me a single situation where you would want to mark a cell to raise an exception, but that exception doesn’t happen every single time?

Sorry for repeating myself, I’ve already asked this above (https://github.com/jupyter/nbconvert/issues/730#issuecomment-356867251), but I didn’t get an answer. There was also some discussion over there: https://github.com/jupyter/notebook/issues/4198#issuecomment-438630006, where I didn’t get a satisfactory answer, either.

I believe there is not a single reasonable case where an exception would be expected only some of the times.

Therefore, if nbconvert would hypothetically change its behavior, the only cases where an expected exception would not happen (i.e. the only situation where anyone would even realize that something has changed), would be cases where the raises-exception tag was applied erroneously. And that’s good, because then the tag can be removed to avoid the problems I’ve described above (https://github.com/jupyter/nbconvert/issues/730#issuecomment-438223813).

mgeier on Apr 24, 2019