Error statuses versus exceptions in DynamoDB in Dotnet SDK

When using the AWS SDK for .NET with DynamoDB, you can rely on the SDK to throw exceptions when error conditions arise. The AWS SDKs, including the .NET SDK, are designed to automatically propagate errors from DynamoDB to your application in the form of exceptions.

When DynamoDB can't process a request, it returns an HTTP error code and message. The AWS SDK handles these responses and converts them into appropriate exceptions that you can catch in your code. This means you don't need to manually check HTTP status codes - the SDK does this for you.

For error handling in your .NET application, you should implement try-catch blocks to catch and handle these exceptions. The exceptions thrown will be specific to the type of error that occurred. For example, you might encounter exceptions like:

• ResourceNotFoundException (when a requested resource doesn't exist)
• ProvisionedThroughputExceededException (when you exceed your provisioned throughput)
• ConditionalCheckFailedException (when a condition in your request evaluates to false)

While the specific exception hierarchy in .NET isn't detailed in the available information, the pattern is similar across AWS SDKs. In the Java SDK, for instance, there's a hierarchy with SdkServiceException as the base, followed by AwsServiceException and then DynamoDbException, with more specific exceptions under those.

In summary, you just need the "belt" - implementing exception handling in your code is sufficient, and you don't need to also check HTTP status codes (the "suspenders"). The SDK is designed to throw appropriate exceptions when errors occur, allowing you to focus on handling those exceptions in your application logic.
Sources
Error handling with DynamoDB - Amazon DynamoDB
Programming DynamoDB with the AWS SDK for Java 2.x - Amazon DynamoDB
DynamoDB low-level API - Amazon DynamoDB
Programming Amazon DynamoDB with JavaScript - Amazon DynamoDB