xarray
xarray copied to clipboard
Add xarray.backends.NoMatchingEngineError
- [x] Closes #5329
- [x] Tests added
- [x] Passes
pre-commit run --all-files - [x] User visible changes (including notable bug fixes) are documented in
whats-new.rst - [x] New functions/methods are listed in
api.rst
@shoyer I have two suggestions:
- I would very much prefer to have the exception in the top level module in order to allow:
import xarray as xr
try:
ds = xr.open_dataset(...)
except xr.NoMatchingEngineError:
...
- I feel that the error message is very clear, but the name of the exception seems slightly confusing as it appears to imply that no engine can open the dataset when it is only that we couldn't autodetect which engine to use just inspecting at the
filename_or_obj. I would prefer something along the lines ofEngineAutodetectionError. But I don't feel too strong about it.
@alexamici good points! I will revise this soon :)
Hi,
I see this was ready to merge, but I would like to still comment on the error message a bit.
IMO, it should be emphasized a bit more that the file might not exist, which I suspect happens much more often than a backend missing. I came across this PR after me and a colleague struggled with opening a netCDF file for twenty minutes, trying to install different backends and such, until we realized that there was a typo in the filename we were trying to open.
The error message could be something like:
Error opening
{store_spec}: The file does not exist or is not supported by any of xarray's currently installed IO backends{installed}. Consider explicitly ...
It's a small change, but in the current version there is a risk that a beginner who knows nothing about storage backends gets stuck on "did not find a match in any of the installed backends" and goes on a wild goose chase installing packages like we did.
How about inheriting from FileNotFoundError, this Exception type would be the first guess of people. And while at it, you could inherit from ValueError to keep it backwards compatible.