Treat subprocess errors as exceptions

[minrk]

We do some things differently when an exception is met (e.g. abort queued tasks in the kernel). We should probably be treating subprocess errors (!fail, %%script magics) as exceptions in the same way, though we don't want to end up displaying a traceback.

[minrk]

I looked into this a bit, briefly, and the way the kernel notices that an exception happened is by hooking into the traceback-rendering, so anything we do that skips a traceback will also skip the kernel noticing that the exception occurred.

We need a clearer mechanism for the kernel to check "did this cell fail".

[LucianaMarques]

Hi there, is this issue still needing help? Has anyone opened any pull request mentioning it? I would like to work on it.

[adkein]

We do some things differently when an exception is met (e.g. abort queued tasks in the kernel).

Could you please link to a relevant example in the repository of what happens currently when an exception is met?

We should probably be treating subprocess errors (!fail, %%script magics) as exceptions in the same way

Could you link to somewhere in the code base having to do with a subprocess the treatment of whose errors would presumably be changed by a pull request for this issue?

[vikas2323]

I would love to be a part of this. Can someone please explain the what the issue is? Maybe, I could help.

[GSAUC3]

Hi @minrk , I looked into this and found that error handling is already implemented in InteractiveShell.getoutput() and controlled via the system_raise_on_error flag.

When system_raise_on_error = True, both !!cmd and (in the current development version) !cmd raise a CalledProcessError on non-zero exit codes.

I tested this on the latest codebase, and the behavior appears to be consistent.

Could you confirm if this issue still persists on your end? If not, this might already be resolved and could potentially be closed.