Skip to content

Conversation

@takluyver
Copy link
Member

As mentioned in #97, now that handle_value and handle_graphics can call third-party code via repr, we should catch failures in those so they don't crash the kernel.

As mentioned in #97, now that handle_value and handle_graphics can call
third-party code via repr, we should catch failures in those so they
don't crash the kernel.
@takluyver takluyver mentioned this pull request Apr 24, 2015
10 tasks
@flying-sheep
Copy link
Member

good idea. should we do that or show a warning and return NULL?

@jankatins
Copy link
Contributor

IMO:

  • errors should be send to a kernel log
  • if one or more non-text/plain repr functions work, only send the ones which return non-NULL values (so e.g. for plotting there is only one missing but plots are still displayed)

No sure what should happen, if all non-text/plain repr_* error: IMO the plain text one should be replaced by the error messages to send this to the users so that their is some info there. But if we per default send pdf and that would be the only one which is send back because all other image types error, then the notebook will only display the text plain one which will not have the error message :-(

@takluyver
Copy link
Member Author

In IPython, we switched from showing a warning for repr failures to just treating it as an error, so that's what I'm following here. It's easier to debug an error than something showing up not as you expect.

@jankatins
Copy link
Contributor

@takluyver ok, then LGTM

takluyver added a commit that referenced this pull request Apr 26, 2015
Catch failures from repr and display the error
@takluyver takluyver merged commit 4f76932 into master Apr 26, 2015
@takluyver takluyver deleted the catch-repr-failures branch April 26, 2015 17:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants