Refactor SDK's error types about aws-sdk-go-v2 HOT 5 CLOSED

Looks like Go1.13 may have more error inspection capabilities. We should consider it part of this.

golang/go#29934

https://godoc.org/golang.org/x/xerrors

https://tip.golang.org/pkg/errors/
https://tip.golang.org/pkg/fmt/#Errorf

from aws-sdk-go-v2.

Thanks for the suggestion @rajender. I agree taking advantage of xerrors package with 1.13 would help to standardize the SDK's error chaining. Right now this chaining is an odd mix of hand rolled chain, and github.com/pkg/errors.

This would mean the SDK's minimum supported version would raise go Go 1.13. Since the SDK is still in developer preview, this is may not be a deal breaker, but 1.13 most likely won't release until around August. The SDK may need to consider back filling support for xerrors for older version of Go if 1.13 ends up being too recent of a change when the SDK does GA release.

from aws-sdk-go-v2.

APIErrors returned from an API operation call should probably include the metadata for the operation request/response that failed. This context would help will logging, and identifying context of a failed operation call.

Does it make sense to expose this behavior to all SDK errors that are returned from an operation call? One way this could happen is the operation's Send potentially could wrap the underlying error to ensure context is maintained.

from aws-sdk-go-v2.

The SDK's error handling refactor should be built with Unwrap in mind so that layering of errors can easily be peeled apart.

from aws-sdk-go-v2.

#487 made significant changes to the SDK's awserr.Error and internal error wrapping. The SDK now supports Unwrap in numerous places in the SDK.

There are still several instances of SDK logic errors that are using the awserr.Error Code wrapper. Ideally the SDK doesn't use awserr.Error for any non-API error response. All SDK logic errors are typed, or generic errors. The outstanding SDK logic awserr.Error usage are a good target for further burn down.

from aws-sdk-go-v2.