exceptionfactory commented on a change in pull request #4917:
URL: https://github.com/apache/nifi/pull/4917#discussion_r599236166
##########
File path:
nifi-nar-bundles/nifi-azure-bundle/nifi-azure-processors/src/main/java/org/apache/nifi/processors/azure/storage/PutAzureBlobStorage.java
##########
@@ -141,14 +142,14 @@ public void onTrigger(final ProcessContext context, final
ProcessSession session
}
try {
- blob.upload(in, -1, null, null, operationContext);
+ uploadBlob(blob, operationContext, in);
BlobProperties properties = blob.getProperties();
attributes.put("azure.container", containerName);
attributes.put("azure.primaryUri",
blob.getSnapshotQualifiedUri().toString());
attributes.put("azure.etag", properties.getEtag());
attributes.put("azure.length", String.valueOf(length));
attributes.put("azure.timestamp",
String.valueOf(properties.getLastModified()));
- } catch (StorageException | URISyntaxException e) {
+ } catch (StorageException | URISyntaxException | IOException
e) {
storedException.set(e);
Review comment:
Reviewing the larger context of this block, is there a reason to
continue maintaining this reference to the `storageException`? The checked
`StorageException` and `URISyntaxException` could be wrapped in the existing
`throw new IOException()`. If there is a particular reason to evaluate or log
the `StorageException`, that could be handled here, or in the outer catch
block. Either way, it seems like it would be worth untangling the exception
handling to avoid this kind of scenario down the road.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
