[ https://issues.apache.org/jira/browse/HADOOP-14582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Steve Loughran updated HADOOP-14582: ------------------------------------ Parent Issue: HADOOP-15132 (was: HADOOP-14552) > 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: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org