[
https://issues.apache.org/jira/browse/HADOOP-14582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16128910#comment-16128910
]
Steve Loughran commented on HADOOP-14582:
-----------------------------------------
+ error codes like ""BlobNotFound" scattered through the code should be pulled
out into their own class and referenced, for consistency of use and ease of
using IDE to find uses of an error.
> WASB exception handling to translate specific failures into specific
> exceptions
> -------------------------------------------------------------------------------
>
> Key: HADOOP-14582
> URL: https://issues.apache.org/jira/browse/HADOOP-14582
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: fs/azure
> Affects Versions: 2.8.1
> Reporter: Steve Loughran
>
> Mucht of the exception handling logic in WASB is a catch-and-wrap-as-IOE
> handler.
> {code}
> } catch (Exception e) {
> // Re-throw the exception as an Azure storage exception.
> throw new AzureException(e);
> }
> {code}
> 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
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
