-
Notifications
You must be signed in to change notification settings - Fork 104
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
Misleading Exceptions #58
Comments
I'd be happy to work on a PR if there is an agreement that this is an issue 😄 |
Thanks @andersbogsnes . Agree this is an issue, and if you have some time to work on it that would be great. However, I added one unit test (test_ls_0), which calls fs.ls("."), and if I |
Ran into some more issues with exceptions here: https://github.com/dask/adlfs/blob/07aabb7beea34b640c75991f07142154f8f39b3c/adlfs/core.py#L754 (It's trying to raise a string, which errors) I'm working on a PR in my downtime, but was wondering if there's a need to introduce an exception hierarchy of some sort. Does fsspec have an opinion on that? What type of exception should be raised here? |
The only error I have seen in this block is a ResourceNotFound error. If we get back something else, we should probably raise a RuntimeError in this block, and propagate the error message {e} back to the user. |
Closed on PR#72 |
I just updated to 0.3.0 and am adapting my own libraries to these changes - great to have support for azure blob storage 12!
I noticed that some of the exceptions are overly broad and gives the end-user a misleading error message.
For example, passing invalid credentials will raise a FileNotFoundError, suppressing Azure Blob Storages AuthorizationFailure.
Example:
While running Azurite:
I would expect to either have a custom exception I can catch, or to let through the Azure exception so that the user can handle it.
As-is, I can't handle an Authentication issue separately from other issues when using adlfs in my libraries.
The text was updated successfully, but these errors were encountered: