# Control de errores con DynamoDB
En esta sección se describen los errores de tiempo de ejecución y se explica cómo controlarlos. También se describen los mensajes y códigos de error específicos de Amazon DynamoDB. Para obtener una lista de los errores comunes que se aplican a todos los servicios de AWS, consulte [Administración de accesos](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/CommonErrors.html)
**Topics**
+ [Componentes de un error](#Programming.Errors.Components)
+ [Errores transaccionales](#Programming.Errors.TransactionalErrors)
+ [Mensajes y códigos de error](#Programming.Errors.MessagesAndCodes)
+ [Control de errores en la aplicación](#Programming.Errors.Handling)
+ [Reintentos de error y retroceso exponencial](#Programming.Errors.RetryAndBackoff)
+ [Operaciones por lotes y control de errores](#Programming.Errors.BatchOperations)
## Componentes de un error
Cuando el programa envía una solicitud, DynamoDB intenta procesarla. Si la solicitud se lleva a cabo correctamente, DynamoDB devuelve un código de estado HTTP de operación correcta (`200 OK`), así como el resultado de la operación solicitada.
Si la solicitud no se realiza correctamente, DynamoDB devuelve un error. Cada error tiene tres componentes:
+ Un código de estado HTTP (por ejemplo, `400`).
+ Un nombre de excepción (por ejemplo, `ResourceNotFoundException`).
+ Un mensaje de error (por ejemplo, `Requested resource not found: Table: tablename not found`).
Los SDK de AWS se encargan de transmitir los errores a la aplicación, para que pueda adoptar las medidas apropiadas. Por ejemplo, en un programa en Java, puede escribir una lógica `try-catch` para controlar una excepción `ResourceNotFoundException`.
Si no utiliza un SDK de AWS, tiene que analizar el contenido de la respuesta de bajo nivel de DynamoDB. A continuación se muestra un ejemplo de este tipo de respuesta.
```
HTTP/1.1 400 Bad Request
x-amzn-RequestId: LDM6CJP8RMQ1FHKSC1RBVJFPNVV4KQNSO5AEMF66Q9ASUAAJG
Content-Type: application/x-amz-json-1.0
Content-Length: 240
Date: Thu, 15 Mar 2012 23:56:23 GMT
{"__type":"com.amazonaws.dynamodb.v20120810#ResourceNotFoundException",
"message":"Requested resource not found: Table: tablename not found"}
```
## Errores transaccionales
Para obtener información sobre los errores transaccionales, consulte . [Gestión de conflictos de transacciones en DynamoDB](transaction-apis.md#transaction-conflict-handling)
## Mensajes y códigos de error
A continuación se muestra una lista de excepciones devueltas por DynamoDB, agrupados por su código de estado HTTP. Si *¿Reintentar?* es *Sí*, puede volver a enviar la misma solicitud. Si *¿Reintentar?* es *No*, debe corregir el problema en el lado del cliente antes de volver a enviar la solicitud.
### Código de estado HTTP 400
El código de estado HTTP `400` indica que existe un problema en la solicitud; por ejemplo, se ha producido un error de autenticación, faltan parámetros obligatorios o se ha superado el rendimiento aprovisionado de una tabla. Debe corregir el problema en la aplicación antes de volver a enviar la solicitud.
**AccessDeniedException **
Mensaje: *Access denied.*
El cliente no firmó correctamente la solicitud. Si utiliza un SDK de AWS, las solicitudes se firman automáticamente; en caso contrario, visite [Proceso de firma de Signature Version 4](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html) en la *Referencia general de AWS*.
¿Reintentar? No
**ConditionalCheckFailedException**
Mensaje: *The conditional request failed. *
Ha especificado una condición que se ha evaluado en false. Por ejemplo, es posible que haya intentado realizar una actualización condicional de un elemento, pero que el valor real del atributo no coincidiese con el valor previsto en la condición.
¿Reintentar? No
**IncompleteSignatureException**
Mensaje: *La firma de solicitud no cumple los estándares de AWS)*.
La firma de la solicitud no incluía todos los componentes necesarios. Si utiliza un SDK de AWS, las solicitudes se firman automáticamente; en caso contrario, visite [Proceso de firma de Signature Version 4](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html) en la *Referencia general de AWS*.
¿Reintentar? No
**ItemCollectionSizeLimitExceededException**
Mensaje: *Collection size exceeded.*
Para una tabla con un índice secundario local, un grupo de elementos con el mismo valor de clave de partición ha superado el límite de tamaño máximo de 10 GB. Para obtener más información sobre las colecciones de elementos, consulte [Colecciones de elementos en los índices secundarios locales](LSI.md#LSI.ItemCollections).
¿Reintentar? Sí
**LimitExceededException**
Mensaje: *Too many operations for a given subscriber.*
Hay demasiadas operaciones del plano de control simultáneas. El número acumulado de tablas e índices que se encuentren en los estados `CREATING`, `DELETING` o `UPDATING` no puede ser mayor que 500.
¿Reintentar? Sí
**MissingAuthenticationTokenException**
Mensaje: *La solicitud debe contener un ID de clave de acceso de AWS válido (registrado)*.
La solicitud no incluía el encabezado de autorización necesario o el formato de este último era incorrecto. Consulte [API de bajo nivel de DynamoDB](Programming.LowLevelAPI.md).
¿Reintentar? No
**ProvisionedThroughputExceededException**
Mensaje: *You exceeded your maximum allowed provisioned throughput for a table or for one or more global secondary indexes.(Ha excedido el máximo permitido del rendimiento aprovisionado para una tabla con uno o más índices secundario globales) To view performance metrics for provisioned throughput vs. consumed throughput, open the [Amazon CloudWatch console](https://console.aws.amazon.com/cloudwatch/home) (Para ver las métricas de rendimiento para el rendimiento aprovisionado vs. el rendimiento consumido, abra la consola de Amazon CloudWatch)*.
El error incluye una lista de campos de `ThrottlingReason` que proporciona un contexto específico sobre por qué se produjo la limitación, siguiendo el formato `ResourceType+OperationType+LimitType` (por ejemplo, `TableReadProvisionedThroughputExceeded`) y el ARN del recurso afectado. Esto le ayuda a identificar qué recurso se está limitando (tabla o índice), qué tipo de operación desencadenó la limitación (lectura o escritura) y el límite específico que se superó (en este caso: capacidad aprovisionada). Para obtener más información sobre el diagnóstico y la resolución de problemas de limitación, consulte [Diagnóstico de limitación](throttling-diagnosing-workflow.md).
Ejemplo: La velocidad de solicitudes es demasiado alta. Los SDK de AWS para DynamoDB reintentan automáticamente las solicitudes que reciben esta excepción. La solicitud se llevará a cabo con éxito en algún momento, salvo que la cola de reintentos sea demasiado larga para que pueda alcanzarse el final. Reduzca la frecuencia de las solicitudes mediante [Reintentos de error y retroceso exponencial](#Programming.Errors.RetryAndBackoff).
¿Reintentar? Sí
**ReplicatedWriteConflictException**
Mensaje: *Una solicitud de otra región está modificando uno o más elementos de esta solicitud.*
Ejemplo: se solicitó una operación de escritura para un elemento de una tabla global de alta coherencia de varias regiones (MRSC) que actualmente está siendo modificado por una solicitud de otra región.
¿Reintentar? Sí
**RequestLimitExceeded**
Mensaje: *Throughput exceeds the current throughput limit for your account (El rendimiento supera el límite de rendimiento actual de su cuenta). Para solicitar un aumento del límite, contacte con AWS Support en [https://aws.amazon.com/support](https://aws.amazon.com/support)*.
El error incluye una lista de campos de `ThrottlingReason` que proporciona un contexto específico sobre por qué se produjo la limitación, siguiendo el formato `ResourceType+OperationType+LimitType` (por ejemplo, `TableWriteAccountLimitExceeded` o `IndexReadAccountLimitExceeded`) y el ARN del recurso afectado. Esto le ayuda a identificar qué recurso se está limitando (tabla o índice), qué tipo de operación desencadenó la limitación (lectura o escritura) y si ha superado las cuotas de servicio por cuenta. Para obtener más información sobre el diagnóstico y la resolución de problemas de limitación, consulte [Diagnóstico de limitación](throttling-diagnosing-workflow.md).
Ejemplo: La velocidad de las solicitudes bajo demanda excede el rendimiento permitido de la cuenta y la tabla no puede escalarse más.
¿Reintentar? Sí
**ResourceInUseException**
Mensaje: *The resource which you are attempting to change is in use. *
Ejemplo: Ha intentado volver a crear una tabla que ya existía o eliminar una tabla que se encuentra en el estado `CREATING`.
¿Reintentar? No
**ResourceNotFoundException **
Mensaje: *Requested resource not found.*
Ejemplo: La tabla que se ha solicitado no existe o se encuentra demasiado al principio del estado `CREATING`.
¿Reintentar? No
**ThrottlingException**
Mensaje: *Rate of requests exceeds the allowed throughput.*
Esta excepción se devuelve como respuesta de AmazonServiceException con un código de estado THROTTLING\$1EXCEPTION. Esta excepción es posible que se produzca si realiza operaciones de la API de [plano de control](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.API.html#HowItWorks.API.ControlPlane) con demasiada rapidez.
Para las tablas que utilizan el modo bajo demanda, esta excepción es posible que se produzca para cualquier operación de la API de [plano de datos](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.API.html#HowItWorks.API.DataPlane) si la tarifa de solicitud es demasiado alta. Para obtener más información sobre el escalado bajo demanda, consulte [Rendimiento inicial y propiedades de escalado](on-demand-capacity-mode.md#on-demand-capacity-mode-initial).
El error incluye una lista de campos de `ThrottlingReason` que proporciona un contexto específico sobre por qué se produjo la limitación, siguiendo el formato `ResourceType+OperationType+LimitType` (por ejemplo, `TableReadKeyRangeThroughputExceeded` o `IndexWriteMaxOnDemandThroughputExceeded`) y el ARN del recurso afectado. Esta información le ayuda a identificar qué recurso se está limitando (tabla o índice), qué tipo de operación desencadenó la limitación (lectura o escritura) y el límite específico que se superó (límites de partición o rendimiento máximo bajo demanda). Para obtener más información sobre el diagnóstico y la resolución de problemas de limitación, consulte [Diagnóstico de limitación](throttling-diagnosing-workflow.md).
¿Reintentar? Sí
**UnrecognizedClientException**
Mensaje: *The Access Key ID or security token is invalid.*
La firma de la solicitud es incorrecta. La causa más probable es que un ID de clave de acceso o una clave secreta de AWS sean incorrectos.
¿Reintentar? Sí
**ValidationException**
Mensaje: Varía, según el error concreto de que se trate.
Este error se produce por varias razones; por ejemplo, si se ha omitido un parámetro obligatorio, uno de los valores está fuera del rango admitido o los tipos de datos no concuerdan. El mensaje de error contiene información acerca de la parte concreta de la solicitud que ha provocado el error.
¿Reintentar? No
### Código de estado HTTP 5xx
Un código de estado HTTP `5xx` indica un problema cuya resolución corresponde a AWS. Puede ser un error transitorio, en cuyo caso puede reintentar la solicitud hasta que se ejecute satisfactoriamente. En caso contrario, vaya al [panel de AWS Service Health Dashboard](https://status.aws.amazon.com/) para comprobar si existe algún problema operativo con el servicio.
Para obtener más información, consulte [¿Cómo resuelvo los errores HTTP 5xx en Amazon DynamoDB?](https://aws.amazon.com/premiumsupport/knowledge-center/dynamodb-http-5xx-errors/)
**InternalServerError (HTTP 500)**
DynamoDB no pudo procesar la solicitud.
¿Reintentar? Sí
Pueden producirse errores internos del servidor cuando se utilizan elementos. Cabe esperar que esto suceda durante la vida útil de una tabla. Todas las solicitudes que producen un error se pueden reintentar inmediatamente.
Cuando se recibe un código de estado 500 en una operación de escritura, es posible que la operación se haya realizado correctamente o haya fallado. Si la operación de escritura es una solicitud `TransactWriteItem`, entonces puede volver a intentar la operación. Si la operación de escritura es una solicitud de escritura de un solo elemento, como `PutItem`, `UpdateItem` o `DeleteItem`, la aplicación debe leer el estado del elemento antes de volver a intentar la operación o utilizar [Ejemplo de la CLI de expresión de condición de DynamoDB](Expressions.ConditionExpressions.md) para asegurarse de que el elemento permanezca en el estado correcto después de volver a intentarlo, independientemente de si la operación anterior se ha realizado correctamente o ha fallado. Si la idempotencia es un requisito para la operación de escritura, utilice [`TransactWriteItem`](transaction-apis.md#transaction-apis-txwriteitems), que admite solicitudes idempotentes especificando automáticamente un `ClientRequestToken` para desambiguar múltiples intentos de realizar la misma acción.
**ServiceUnavailable (HTTP 503)**
DynamoDB no está disponible en este momento. Debería tratarse de un estado temporal.
¿Reintentar? Sí
## Control de errores en la aplicación
Para que la aplicación funcione sin problemas, es preciso agregar lógica que capture los errores y responda a ellos. Los enfoques habituales incluyen el uso de bloques `try-catch` o instrucciones `if-then`.
Los SDK de AWS llevan a cabo sus propios reintentos y comprobaciones de errores. Si se produce algún error al utilizar uno de los SDK de AWS, su código y descripción pueden ayudarle a solucionar el problema.
También debería aparecer el `Request ID` en la respuesta. El `Request ID` puede resultar útil si tiene que acudir a Support de AWS para diagnosticar el problema.
## Reintentos de error y retroceso exponencial
Numerosos componentes de una red, como los servidores DNS, los conmutadores o los balanceadores de carga, entre otros, pueden generar errores en cualquier punto de la vida de una solicitud determinada. La técnica habitual para abordar estas respuestas de error en un entorno de red consiste en implementar los reintentos en la aplicación cliente. Esta técnica aumenta la fiabilidad de la aplicación.
Cada SDK de AWS implementa automáticamente una lógica de reintento. Puede modificar los parámetros de reintento de acuerdo con sus necesidades. Por ejemplo, tomemos una aplicación en Java que requiere una estrategia de conmutación por error rápida y no permite reintentos en caso de error. Con el AWS SDK para Java, podría usar la clase `ClientConfiguration` y proporcionar un valor de `maxErrorRetry` de `0` para desactivar los reintentos. Para obtener más información, consulte la documentación del SDK de AWS del lenguaje de programación específico.
Si no utiliza un SDK de AWS, debe reintentar las solicitudes originales que reciban errores de servidor (5xx). Sin embargo, los errores de cliente (4xx, salvo las excepciones `ThrottlingException` o `ProvisionedThroughputExceededException`) indican que es preciso revisar la solicitud en sí para corregir el problema antes de volver a intentarlo. Para obtener recomendaciones detalladas para abordar situaciones de limitación específicas, consulte la sección de [Solución de problemas de limitación de DynamoDB](TroubleshootingThrottling.md).
Además de los reintentos sencillos, cada SDK de AWS implementa un algoritmo de retroceso exponencial para mejorar el control de flujo. El retardo exponencial se basa en el concepto de utilizar tiempos de espera progresivamente más largos entre reintentos para las respuestas a errores consecutivos. Por ejemplo, las aplicaciones cliente podrían esperar 50 milisegundos antes de llevar a cabo el primer reintento, 100 milisegundos antes del segundo, hasta 200 milisegundos antes del tercero y así sucesivamente. Sin embargo, si la solicitud no se ha llevado a cabo correctamente al cabo de un minuto, el problema podría radicar en que el tamaño de la solicitud supera el rendimiento aprovisionado, y no en la tasa de solicitudes. Establezca el número máximo de reintentos de modo que se detenga al cabo de un minuto. Si la solicitud no se realiza correctamente, investigue las opciones de rendimiento aprovisionado.
**nota**
Los SDK de AWS implementan una lógica de reintento automático y retroceso exponencial.
La mayoría los algoritmos de retardo exponencial utilizan la fluctuación (el retraso aleatorio) para evitar conflictos sucesivos. Habida cuenta de que no está intentando evitar este tipo de conflictos en estos casos, no es preciso utilizar este número aleatorio. Sin embargo, si utiliza clientes simultáneos, la fluctuación puede ayudar a que las solicitudes tengan éxito con mayor rapidez. Para obtener más información, consulte la entrada del blog sobre [Exponential Backoff and Jitter](http://www.awsarchitectureblog.com/2015/03/backoff.html) (Retroceso exponencial y fluctuación).
## Operaciones por lotes y control de errores
La API de bajo nivel de DynamoDB admite las operaciones por lote de lectura y escritura. `BatchGetItem` lee elementos en una o varias tablas y `BatchWriteItem` coloca o elimina elementos en una o varias tablas. Estas operaciones por lote se implementan como encapsuladores en torno a otras operaciones de DynamoDB que no son por lote. Es decir, `BatchGetItem` invoca `GetItem` una vez para cada elemento del lote. De igual forma,`BatchWriteItem` invoca `DeleteItem` o `PutItem`, según proceda, para cada elemento del lote.
Una operación por lotes puede tolerar que algunas solicitudes individuales del lote no se lleven a cabo. Por ejemplo, tomemos una solicitud `BatchGetItem` para leer cinco elementos. Aunque algunas de las solicitudes `GetItem` subyacentes no se realicen, esto no provocará un error de toda la operación `BatchGetItem`. Sin embargo, si las cinco operaciones de lectura fallan, entonces el `BatchGetItem` completo falla.
Las operaciones por lotes devuelven información sobre las solicitudes individuales que no se realizan, para que pueda diagnosticar el problema y reintentar la operación. Para `BatchGetItem`, las tablas y claves principales en cuestión se devuelven en el valor `UnprocessedKeys` de la respuesta. Para `BatchWriteItem`, se devuelve información similar en `UnprocessedItems`.
La causa más probable de que no se realice una lectura o una escritura es la *limitación controlada*. Para `BatchGetItem`, una o varias tablas de la solicitud por lotes no tiene suficiente capacidad de lectura aprovisionada para admitir la operación. Para `BatchWriteItem`, una o varias de las tablas no tiene suficiente capacidad de escritura aprovisionada.
Si DynamoDB devuelve elementos sin procesar, debe reintentar la operación por lote para estos elementos. Sin embargo, *recomendamos encarecidamente utilizar un algoritmo de retardo exponencial*. Si reintenta la operación de forma inmediata, podría volver a producirse un error en las solicitudes subyacentes de lectura o escritura a causa de la limitación controlada de las tablas individuales. Si retrasa la operación por lotes mediante el retardo exponencial, será mucho más probable que las solicitudes individuales del lote se lleven a cabo correctamente.
**nota**
Algunos AWS SDK proporcionan clientes de nivel superior que gestionan automáticamente los reintentos de elementos no procesados, por lo que no es necesario que implemente esta lógica de reintentos usted mismo. Por ejemplo:
**Java**: tanto el [Cliente mejorado de DynamoDB](DynamoDBEnhanced.md) de la versión 2 de AWS SDK para Java como el [DynamoDBMapper](DynamoDBMapper.md) de la versión 1 reintentan automáticamente los elementos no procesados al realizar operaciones por lotes.
**Python**: el recurso `batch_writer` de la tabla boto3 gestiona implícitamente los reintentos de elementos no procesados para las operaciones de escritura por lotes. Para obtener más información, consulte [Uso del recurso de tabla batch\$1writer](programming-with-python.md#programming-with-python-batch-writer).
Si utiliza un cliente de bajo nivel o un SDK que no ofrece este comportamiento, debe implementar usted mismo la lógica de reintento, tal y como se ha descrito anteriormente.