[ESI] Don't swallow exception in callback port wrapper #8913
Conversation
I'm open to convincing, but I don't think the type conversion wrapper should swallow an exception occuring during argument deserialization and callback handling. Users of the ESI runtime may have other logging mechanisms active, so catching and printing an exception through `traceback` doesn't make sense to me. This PR removes that, and assumes that the user of the callback port is able to handle exceptional cases.
There was a problem hiding this comment.
The problem here is that the exception (IIRC) goes directly back to the C++ runtime code. So python user code never sees the exception and doesn't have the chance to catch it.
You do have a point about not swallowing (de-)serialization errors. It's actually worse than that because the hardware is waiting on a response. Really the error should propagate through the runtime back to the hardware.
Perhaps we should have a second callback which gets called on an exception being thrown in the callback. (This applies both to C++ and Python.) It should contain both the exception handling code and return the response to hardware. If that callback throws an exception, the application throws the exception back to the user and crashes. Of course all of this should be logged. I think that the exception cb should be optional and the default should be to crash.
Next time something connects to the hardware, however, it'd have to deal with hardware which might be in a wedged state... Ideally, we'd have a watchdog in hardware to monitor all of these requests and report to the software that it is in a wedged state. That's a more general problem so I just wanted to note it.
Why does python user code have to see it? For me, the exception going back to the C++ should be the expected behavior. Then that runtime has proper exception handling and forwarding of whatever error state that gets produced by the deserialization error. |
In the C++ case, no serialization or de-serialization occurs so the callback function has the ability to catch exceptions stemming from (de-)serialization issues. In the python case, the (de-)serialization occurs before and after the callback runs so it doesn't get the chance to catch exceptions. Also, I'm not sure what happens if an exception gets into the C++ runtime from a callback... So this is something which definitely needs to be tested. |
I'm open to convincing, but I don't think the type conversion wrapper should swallow an exception occuring during argument deserialization and callback handling. Users of the ESI runtime may have other logging mechanisms active, so catching and printing an exception through
tracebackdoesn't make sense to me.This PR removes that, and assumes that the user of the callback port is able to handle exceptional cases.