Skip to content
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

Better traceback. #1247

Open
Carreau opened this issue Mar 22, 2016 · 9 comments
Open

Better traceback. #1247

Carreau opened this issue Mar 22, 2016 · 9 comments
Milestone

Comments

@Carreau
Copy link
Member

Carreau commented Mar 22, 2016

Again, JupyterDay Boston,

I had also many request for "HTML expandable tracebacks". This might be more an IPython issue, i just don't remember if tracebacks support mimetype in notebooks.

@takluyver
Copy link
Member

We had talked about adding a new message type for errors with a mimebundle (the present error message only has a text traceback).

Thinking about it more, I'm not sure we need a new message type: maybe messages should just display with display_data, and then execute_reply with status error is the programmatic indicator that it failed.

@minrk
Copy link
Member

minrk commented Mar 23, 2016

I don't recall a proposal for a new message type. My understanding of the plan was to extend the existing error message with richer data (possibly mimebundle, possibly structured in a more traceback-centric way), so that exceptions can be better rendered.

@takluyver
Copy link
Member

Oh, that may have been it. A backward-compatible change to the message spec, anyway.

If we do want to use a mimebundle (which I think is a simple enough extension), I think it's worth considering just doing that with the existing display_data message, though - I'm not sure there's any reason to add a mimebundle to error messages.

@minrk
Copy link
Member

minrk commented Mar 23, 2016

There is a reason to add it to the same message in that I think it would make it simpler to do a backward-compatible upgrade without anyone displaying a traceback twice. That might not be true, though; I haven't though about it thoroughly.

@takluyver
Copy link
Member

I was thinking of just switching over to display_data messages and dropping the use of error messages entirely. There's still the execute_reply to provide a programmatic indication that execution failed.

@Carreau Carreau modified the milestone: wishlist Jun 17, 2016
@JamiesHQ
Copy link
Member

cc @gnestor

@gnestor
Copy link
Contributor

gnestor commented May 31, 2017

If I understand correctly, this (custom mimetype and renderer for errors and tracebacks) is already implemented in jupyterlab:

image

As for "expandable" tracebacks, that sounds cool and I'd be willing to work on it.

The question: Should we implement this in classic notebook or dedicate our resources to jupyterlab?

@jankatins
Copy link
Contributor

The jupyter extension repo has a plugin, which does some visual stuff to a traceback: http://jupyter-contrib-nbextensions.readthedocs.io/en/latest/nbextensions/skip-traceback/readme.html

@gnestor
Copy link
Contributor

gnestor commented May 31, 2017

This is a perfect application for a mime renderer extension. As stated above, jupyterlab ships with one, but it appears like it only modifies the background color of the output area. This skip-traceback extensions makes me think that we could do a lot better. We could provide an accordion like UI for tracebacks, error styles, and potentially auto-link references to local file resources. Another great thing about mime renderer extensions: they work for all kernels, so as long at kernels use display_data messages to return errors and conform to a standard spec for this custom mimetype, then all kernels can display errors in very nice way.

cc @ellisonbg @jasongrout @blink1073 @afshin

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants