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

Improve exceptions on data interface constructor #1127

Closed
philippjfr opened this Issue Feb 12, 2017 · 6 comments

Comments

Projects
None yet
2 participants
@philippjfr
Member

philippjfr commented Feb 12, 2017

Currently we generate a fairly useless exception message if no interface is able to process the data:

ValueError: None of the available storage backends were able to support the supplied data format.

There's a fairly good reason to have done this because we don't want to see exceptions from all the interfaces it tries, but when you're trying to debug what has gone wrong this output is just entirely unhelpful. We should find some way to summarize and report the exceptions raised by the individual interfaces.

@philippjfr philippjfr added the data label Feb 12, 2017

@jlstevens

This comment has been minimized.

Member

jlstevens commented Feb 12, 2017

We probably need some logic in the section of the code where the different data interfaces are tried out to retain this information. Maybe we could keep this info on a hidden class attribute where you can see the exception and traceback for each interface tested.

Alternatively, maybe we could show the real exception but only if the length of the data interface list is one. Having only one possible interface to try means there is no ambiguity about which interface should be used which means any exceptions and tracebacks generated should be shown - this seems like sensible behavior to implement whether or not we do anything else.

@philippjfr philippjfr added this to the v2.0 milestone Mar 15, 2017

@philippjfr

This comment has been minimized.

Member

philippjfr commented Apr 10, 2017

I have a new suggestion, how about when the data is one of the expected formats and all the interfaces fail to interpret the data it raises the exception for the prioritized interface, e.g. when passing in an xarray.Dataset you see the exception raised by the XArrayInterface and the same happens for dataframes, dictionaries, arrays and iris cubes. In case of passing in a list or tuple you still wouldn't see an error but at least the unambiguous data types could raise meaningful exceptions.

@jlstevens

This comment has been minimized.

Member

jlstevens commented Apr 10, 2017

... it raises the exception for the prioritized interface

You mean you see the traceback from the interface that recognized the type/format but failed in some other way? What do you mean by ' prioritized interface'?

@philippjfr

This comment has been minimized.

Member

philippjfr commented Apr 10, 2017

You mean you see the traceback from the interface that recognized the type/format but failed in some other way?

Right.

@jlstevens

This comment has been minimized.

Member

jlstevens commented Apr 10, 2017

Ok, in that case I have two questions:

  1. What bit of an interface will state whether the data is recognized or not even if there is a later exception?
  2. What happens if the data is really odd and nothing recognizes it?
@philippjfr

This comment has been minimized.

Member

philippjfr commented Dec 8, 2017

I've introduced DataErrors which allow raising more informative error messages from within an interface, so I'll close this. Concrete suggestions for improvements should be filed in #2101.

@philippjfr philippjfr closed this Dec 8, 2017

@philippjfr philippjfr modified the milestones: v2.0, v1.10 Feb 5, 2018

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