Translate S3Exception for headObject and headBucket

[zoewangg]

• Translate S3Exception for headObject and headBucket via interceptor
  Throw NoSuchKey exception for headObject and NoSuchBucket exception for headBucket for 404 status code.

• Added modifyException interceptor method

All S3 integration tests passed

[millems]

Should we go all-out and propagate SdkException? All of the exceptions? Do we have similar behavior for the other on* methods, that suppresses exceptions that are thrown?

[dagnir]

The swallowing behavior is only onExecuteFailure since at this point there's already an Exception thrown higher up. The other on* methods let the exception propagate

aws-sdk-java-v2/core/sdk-core/src/test/java/software/amazon/awssdk/core/client/AsyncClientHandlerInterceptorExceptionTest.java

Lines 142 to 160 in fee061b

	@Test
	public void test() {
	if (hook != Hook.ON_EXECUTION_FAILURE) {
	doVerify(() -> clientHandler.execute(executionParams), (t) -> t.getCause().getCause().getMessage().equals(hook.name()));
	} else {
	// ON_EXECUTION_FAILURE is handled differently because we don't
	// want an exception thrown from the interceptor to replace the
	// original exception.
	doVerify(() -> clientHandler.execute(executionParams),
	(t) -> {
	for (; t != null; t = t.getCause()) {
	if (Hook.ON_EXECUTION_FAILURE.name().equals(t.getMessage())) {
	return false;
	}
	}
	return true;
	});
	}
	}

[zoewangg]

I'm fine with propagating SdkException. @shorea Do you have any concerns?

[shorea]

Should we add another interceptor method that lets you modify the exception so you don't have to throw?

[millems]

Andrew coming in with the BIG ideas. I like it!

[zoewangg]

Added modifyException interceptor method.

[millems]

Long-term, should we push these upstream to s3?

[zoewangg]

Yeah, we should.