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").
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.
make ConsoleWidget LoggingConfigurable
This adds the attribute Widget.log, which is hooked up to the
running application's logger.
Don't assume history request succeeded
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'.
retry aborted history requests in qtconsole
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.