azure.storage.filedatalake.models.StorageErrorException does not exist

• Package Name: azure-storage-file-datalake
• Package Version: 12.1.2
• Operating System:Linux
• Python Version: 3.7.3

Describe the bug The docs refer to azure.storage.filedatalake.models.StorageErrorException, but azure.storage.filedatalake.models.StorageErrorException does not seem to exist.

To Reproduce Steps to reproduce the behavior:

>>> import azure.storage.filedatalake
>>> import azure.storage.filedatalake.models
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ModuleNotFoundError: No module named 'azure.storage.filedatalake.models'
>>> import azure.storage.filedatalake.models.StorageErrorException
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ModuleNotFoundError: No module named 'azure.storage.filedatalake.models'
>>> azure.storage.filedatalake._generated.models.StorageErrorException
<class 'azure.storage.filedatalake._generated.models._models_py3.StorageErrorException'>

Expected behavior Documented classes should exist. 😃 Exception classes should be publicly accessible so they may be caught and examined by the caller.

Additional context We catch these exceptions to check for the string ‘This operation is only supported on a hierarchical namespace account.’

[tasherif-msft]

Hi @jazelenk, sorry for the delay on this! you’re right the exceptions docs are not very clear. The azure storage exceptions that are raised at the end of any failed operation are imported from Azure core.

The way we raise this is by using an internal class called StorageErrorException. This is deserialized by process_storage_error(storage_error_exception_object) internally. This simply maps the different possible error codes to the corresponding appropriate Azure core exception which can be caught by the user. You can see the mapping we’re doing here: https://github.com/Azure/azure-sdk-for-python/blob/8504f6d247badd2fd60dce3457f201f9e2b1c079/sdk/storage/azure-storage-blob/azure/storage/blob/_shared/response_handlers.py#L86

As for fetching the specific error code of the exception (which - as you mentioned, would be package specific ) you can follow this example:

# assume we tried to create a container that already exists
# you can catch it and get the specific error code by:

from azure.core.exceptions import ResourceExistsError
try:
  # try to create container logic
except ResourceExistsError as e:
    # this would print StorageErrorCode.container_already_exists
    print(e.error_code)

If for some reason we deserialized an error that is not defined in https://github.com/Azure/azure-sdk-for-python/blob/8504f6d247badd2fd60dce3457f201f9e2b1c079/sdk/storage/azure-storage-blob/azure/storage/blob/_shared/response_handlers.py#L86 we default/raise an HttpResponseError (you can catch it and use the code above to find out what the error code was)

In your case HierarchicalNamespaceNotEnabled is not being deserialized in our checks so you can do the following:

from azure.core.exceptions import HttpResponseError
try:
    ...
except HttpResponseError as e:
    # this would print HierarchicalNamespaceNotEnabled
    print(e.error_code)

I’m not sure why we even reference StorageErrorException in our README. I will put out a PR that explains what I have mentioned in this comment 😃 I will link it here once up. Let me know if this makes sense or if you need further help!

[jazelenk]

The check I end up performing is matching error_code to HierarchicalNamespaceNotEnabled.