-
-
Notifications
You must be signed in to change notification settings - Fork 4.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Crash handler initialization is too aggressive #695
Milestone
Comments
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. |
I see two ways to address the obvious issue above of bad user config causing crashes.
|
mattvonrocketstein
pushed a commit
to mattvonrocketstein/ipython
that referenced
this issue
Nov 3, 2014
Use a much more restrained crash handler by default. Now the excepthook shows a regular traceback, with a brief message about reporting bugs and how to enable to the big crash handler. Our previous, extremely verbose crash handler can still be activated via `%config Application.verbose_crash=True`, so we can debug real crashes or ask users for extra detail easily. Small fixes along the way: * current Application added to configurables list, for use in %config. * email addresses in full crash reports changed to ipython-dev, so they don't go straight to individual users. Should close ipython#695, and ameliorate ipython#833 (doesn't fix the bug, but the message is more sensible).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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:
The crash report gives the incorrect impression that IPython has done something wrong.
The text was updated successfully, but these errors were encountered: