Runtime error handling #135
Conversation
PhilippPlank
added
1-bug
|
Updated initial commit. I come across the channel size which is 64 at the moment for pypy channels. Why is it 64? I needed to increase it a bit in order to send a longer error message over the channels. I think this should work now and stop all running process model threads, if there are one or multiple errors in the process models. PS: The checks will fails, since I do not know how to assert for multiple Exceptions raised and the 64 is also checked in a unit test. |
|
Wouldn't a simply pipe like in this example be simpler through which you can just push the exception as is? I see no need to manually serialize the exception and push it through CSP channels. Error handling is not performance critical at all. |
|
I adopted the behavior to your suggestion @awintel If there is an error is still communicated via csp channels, but the traceback of the exception is stored within the Process of multiprocessing, which we can then fully print out. This also allows unit tests to actually succeed. |
| actors.join() | ||
| if actors.exception: | ||
| _, traceback = actors.exception | ||
| print(traceback) |
There was a problem hiding this comment.
Does this actually identify the problem from which the error came? Perhaps attach this to the Exception object.
You should print the class name, Process name and id.
There was a problem hiding this comment.
To be clear. Both the processes should identify themselves but also the RuntimeServices in case the error happened in the RuntimeService.
Perhaps you even want to distinguish them clearly in the command line prints.
Perhaps you even want to first print a summary of everything that has thrown any errors at the top of the command line to orient the user because otherwise there could be quite a messy stack trace.
There was a problem hiding this comment.
The printed traceback leads you to the line of code the exception occurred, e.g., "line 50, in run_spk
raise AssertionError("All the error info")" -> line 50 is within PyProcModel1. So you know exactly which exception happened and on which code line.
These tracebacks are printed for every exception occurred in all ProcessModels.
| print(traceback) | ||
| error_cnt += 1 | ||
|
|
||
| raise RuntimeError( |
There was a problem hiding this comment.
You could define own Execptions. RuntimeError for actual errors in the Runtime and ProcessModelError for ... you know what.
There was a problem hiding this comment.
This exception is a RuntimeError, due to other Exceptions happened in the ProcessModel. The details have been printed already, this is just to stop the Runtime and tell the user that there have been other Exceptions (+ the number of them).
For all the details the user only has to scroll upwards in the console.
* - Initial commit on passing exception from ProcessModels up to the runtime * - Initial commit on passing exception from ProcessModels up to the runtime * - Updated commit on passing exception from ProcessModels up to the runtime * - Updated commit on passing exception from ProcessModels up to the runtime
Solving the issue of deadlock in the runtime if any ProcessModel throws an exception. (Issue #83)
Also passing the exception all the way up to the runtime. (model -> runtime_service -> runtime)
Open for discussion is the usage of existing csp_ports for error messages or if there are better ways to transport the exception to the runtime.
Edit: the unit test currently does not really work as unit test, but shows a use case.