Skip to content
This repository

Crash handler initialization is too aggressive #695

Closed
minrk opened this Issue August 11, 2011 · 2 comments

2 participants

Min RK Fernando Perez
Min RK
Owner

We currently initialize the crash-handler first, before instantiating any classes. This means that any errors in startup will get a massive, largely meaningless, crash report, that obscures relevant information more than it helps.

We should probably initialize the crash-handler very last, as part of the Application.start method, so that startup errors are raised as simple exceptions, rather than crashes.

For instance, it's trivially easy to crash IPython right now, by simply giving invalid values for configurables:

ipython --colors=bananaphone

The crash report gives the incorrect impression that IPython has done something wrong.

Min RK
Owner

It should probably also be an option to select a less verbose crash-handler, that doesn't print massive amounts of information, even when the crashes are real.

Min RK
Owner

I see two ways to address the obvious issue above of bad user config causing crashes.

  1. Never crash on a TraitError. This is more aggressive protection from TraitErrors causing a crash report, and could potentially prevent the massive crash report if there really is an IPython bug that manifests as a TraitError.
  2. explicitly catch TraitErrors during initialization. This requires a lot more code fiddling, adding try/except blocks (either via decorators or context managers) to every initialize (or init_foo) method.
Fernando Perez fperez closed this in 493f6d4 November 20, 2011
Fernando Perez fperez referenced this issue from a commit January 10, 2012
Commit has since been removed from the repository and is no longer available.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.