include stream output in CellExecutionError

[minrk]

stream output may be useful for diagnosis, and does not appear to be captured for review elsewhere. I recently encountered a tricky to debug error because of a doubly-displayed error where the 'real' error is displayed earlier, while the terminating exception referred to prior output.

Example output:

An error occurred while executing the following cell:
------------------
import sys
print("hello")
print("errorred", file=sys.stderr)
# üñîçø∂é
raise Exception("message")
------------------

----- stdout -----
hello
----- stderr -----
errorred
------------------

---------------------------------------------------------------------------
Exception                                 Traceback (most recent call last)
Cell In[1], line 5
      3 print("errorred", file=sys.stderr)
      4 # üñîçø∂é
----> 5 raise Exception("message")

Exception: message
Exception: message

Things to consider:

• just concatenate streams instead of using stream labels? This would be more concise, cleaner, but lose some information
• add an option, and make including stream output opt-out or opt-in. Could even be per-channel.
• (configurable?) truncation limit, since stream output can be arbitrarily large

[davidbrochart]

Thanks @minrk, it looks like the test failures are relevant?

[minrk]

Yes, I think they are. I'm trying to figure out exactly what Windows does differently re: unicode and how to account for it. The behavior looks correct, it's just the test to actually check for unicode output (not affected or added by this PR, but never tested before because it was within a pytest.raises context after the exception, so never checked).

[minrk]

Actually, on further debugging it seems the unicode behavior is not correct on Windows (perhaps a wrong encoding somewhere?). Since that's not added or changed by this PR, is it okay to skip just that check, and restore it in a dedicated issue for Windows unicode issues?

[davidbrochart]

is it okay to skip just that check, and restore it in a dedicated issue for Windows unicode issues?

Sounds good.

Things to consider:

• just concatenate streams instead of using stream labels? This would be more concise, cleaner, but lose some information
• add an option, and make including stream output opt-out or opt-in. Could even be per-channel.
• (configurable?) truncation limit, since stream output can be arbitrarily large

Interesting ideas to keep in mind, maybe in other PRs?

[minrk]

Interesting ideas to keep in mind, maybe in other PRs?

I'm okay with this PR as-is if others are. Those were just the unaddressed ideas I had so far.

[davidbrochart]

It looks like tests have to be updated?

[davidbrochart]

Thanks @minrk !