Don't assume history requests succeed in qtconsole #745
Conversation
This adds the attribute Widget.log, which is hooked up to the running application's logger.
errors in startup can cause the history request to be aborted. There could be any of a number of reasons the history request should fail, and the frontend should *never* assume that the status is 'ok'.
|
Thanks for the fix, Min. I noticed this crash recently myself. That said, this approach makes me a little leery. The Qt console (and no doubt other frontends as well) makes many different requests: for execution, history, tab completion, object info, etc. It seems painful to have check status and possibly retry the request under all these differences circumstances. I wonder if it possible to abstract at least some of this away, e.g. by having BaseFrontendMixin handle the retries automatically. This is all somewhat vague. I will think about this some more and see if I can produce anything more substantial. |
|
OK, I have an implementation plan for more robust error handling. Since this will involve some refactoring, I think it's worth merging this now as an interim fix. |
Don't assume history requests succeed in qtconsole closes gh-667
Don't assume history requests succeed in qtconsole closes ipythongh-667
If there was an error in user startup code, the history request will be aborted. It is generally not acceptable in frontends to assume that requests succeed. This assumption is made all over our frontend code, and should be be fixed. For now, this handles a known issue of the qtconsole crashing hard when invalid input is given to startup code (e.g.
ipython qtconsole -c "DNE").If the history request was aborted (this means a different request raised an error, causing the queue to be flushed), it will be tried again, exactly once, after waiting for the abort flush.