Proposed new feature or change:
It would be convenient to have custom error types in uxarray. This could help with quickly presenting the relevant info, and also improves error handling for packages using This could speed up debugging, and enable cleaner try.. except error handling. For example, we might define:
class DataCenteringError(ValueError):
""""raised when data is not centered properly, e.g. expected node centered data but got edge centered."""
pass
class DimensionalityError(ValueError):
"""raise when there are the wrong number of dimensions, or dimensions have wrong names."""Then we can change the relevant code which raises ValueError to instead raise a more specific error, e.g., in plotting routines when there are too many dimensions, we can raise DimensionalityError(f"Expected data with a single dimension (other axes may be length 1), "but got dims {data.dims} with shape {data.shape}.") instead of raising a ValueError. Similarly, in aggregation.py, we could raise DataCenteringError(f"Data Variable must be mapped to the corner nodes of each face") instead of just a ValueError.
xarray doesn't use custom error classes, but other popular scientific packages like numpy and pandas do. There isn't much cost to setting it up, and it would make the errors easier to read. Another benefit is cleaner error handling in the future, e.g. if you know some code might involve arrays with the wrong number of dimensions, you can except DimensionalityError without worrying about accidentally catching an unrelated ValueError. Additionally, it will be fully backwards compatible, e.g. except ValueError would still catch DimensionalityError, due to subclassing.
This would also help me address #1285, for example, which asks for more descriptive error when dealing with empty uxarrays.
Proposed new feature or change:
It would be convenient to have custom error types in uxarray. This could help with quickly presenting the relevant info, and also improves error handling for packages using This could speed up debugging, and enable cleaner try.. except error handling. For example, we might define:
Then we can change the relevant code which raises ValueError to instead raise a more specific error, e.g., in plotting routines when there are too many dimensions, we can
raise DimensionalityError(f"Expected data with a single dimension (other axes may be length 1), "but got dims {data.dims} with shape {data.shape}.")instead of raising a ValueError. Similarly, in aggregation.py, we couldraise DataCenteringError(f"Data Variable must be mapped to the corner nodes of each face")instead of just a ValueError.xarraydoesn't use custom error classes, but other popular scientific packages likenumpyandpandasdo. There isn't much cost to setting it up, and it would make the errors easier to read. Another benefit is cleaner error handling in the future, e.g. if you know some code might involve arrays with the wrong number of dimensions, you canexcept DimensionalityErrorwithout worrying about accidentally catching an unrelated ValueError. Additionally, it will be fully backwards compatible, e.g. except ValueError would still catch DimensionalityError, due to subclassing.This would also help me address #1285, for example, which asks for more descriptive error when dealing with empty uxarrays.