Catch failed html_repr for cube #3376
Conversation
| # and so fall back to the default cube repr. | ||
| try: | ||
| result = representer.repr_html() | ||
| except (IndexError, ValueError): |
There was a problem hiding this comment.
My original preference was to catch any exceptions, but I see that's bad practice. Is this too broad a range of exceptions, too narrow, or just right?
| try: | ||
| result = representer.repr_html() | ||
| except (IndexError, ValueError): | ||
| result = None |
There was a problem hiding this comment.
Should we warn that something's gone wrong? It might be weird to not get an html repr of a cube unexpectedly (my preference is no - Iris is loud enough already).
| representer = CubeRepresentation(cube) | ||
|
|
||
| # Confirm we get an exception when we make the html repr... | ||
| with self.assertRaisesRegexp(ValueError, 'substring'): |
There was a problem hiding this comment.
This will stop erroring once #3373 is merged, so we will have to find / cause a different exception in the representer instead...
|
@DPeterK Fancy doing a rebase? |
DPeterK
force-pushed
the
catch_failed_html_repr
branch
from
8055e39
to
de51320
Compare
DPeterK
force-pushed
the
catch_failed_html_repr
branch
from
de51320
to
2d95e74
Compare
|
This seems to have gone stale. We still have ambitions for better HTML, particularly given @pp-mo's work turning the |
In jupyter, if an enhanced repr (such as
_repr_html_) fails, the exception is raised but the execution continues, also returning the standard repr. This is useful for noting that there's a problem with the_repr_html_, but very bad for UX (as reflected in #3351).As such, here we catch exceptions raised by constructing the html repr and explicitly return
Noneso that the default repr is returned instead.