Mucht of the exception handling logic in WASB is a catch-and-wrap-as-IOE handler.
This works, but
- it doesn't offer much in the way of diagnostics
- There's no way to make sense of the failure
- It catches and wraps IOEs, which don't need wrapping
- It can double wrap IOEs around storage exceptions. Example PageBlobInputStream constructor wraps StorageException with IOE; if raised in AzureNativeFileSystemStore.retrieve() it will be caught and wrapped again.
Proposed: something akin to where S3A's translateException is going:
- take an incoming StorageException and based on its errorcode, choose whether or not to wrap in a specific java exception (FNFE, access denied, ...).
- AzureException to make it easy to get at the details
- Include operation & path in error text