Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés. # Control de errores en los flujos de trabajo de Step Functions Todos los estados, excepto los estados `Pass` y `Wait`, pueden encontrar errores de tiempo de ejecución. Los errores pueden ocurrir por varios motivos, como los siguientes: + **Problemas de definición de la máquina de estado**: como un estado Choice sin una regla de coincidencia + **Errores de las tareas**: como una excepción en una función de AWS Lambda + **Problemas transitorios**: por ejemplo, eventos de particiones de red Cuando un estado registra un error, Step Functions genera un error de forma predeterminada para **toda** la ejecución de la máquina de estado. Step Functions también cuenta con características de gestión de errores más avanzadas. Puede configurar su máquina de estado para detectar errores, reintentar los estados fallidos e implementar correctamente los protocolos de control de errores. Los receptores de Step Functions están disponibles para los estados **Task**, **Parallel** y **Map**, pero no para los errores de ejecución de máquinas de estado de nivel superior. Para controlar las ejecuciones que prevé que podrían fallar, el iniciador puede gestionar el error o puede anidar esas ejecuciones dentro de flujos de trabajo secundarios para detectar errores dentro del flujo de trabajo principal. Como alternativa, puede optar por escuchar `TIMED_OUT` los eventos de los flujos de trabajo estándar con un EventBridge bus e invocar una acción para gestionar la ejecución fallida. **Ejemplos prácticos de control de errores** Para implementar un ejemplo de un flujo de trabajo que incluya la gestión de errores, consulte el [Tratamiento de condiciones de error en una máquina de estado de Step Functions](tutorial-handling-error-conditions.md) tutorial de esta guía y la [gestión de errores](https://catalog.workshops.aws/stepfunctions/handling-errors) en *The AWS Step Functions Workshop*. ## Nombres de error Step Functions identifica errores utilizando cadenas que distinguen mayúsculas de minúsculas, lo que se conoce como *nombres de error*. Amazon States Language define un conjunto de cadenas integradas que designan errores conocidos; todas comienzan por el prefijo `States.`. Los estados pueden notificar errores con otros nombres. No obstante, los nombres de error no pueden empezar por el prefijo `States.` Asegúrese de que su código de producción pueda gestionar las excepciones de AWS Lambda servicio (`Lambda.ServiceException`y`Lambda.SdkClientException`). Para obtener más información, consulte [Gestionar excepciones transitorias del servicio de Lambda](sfn-best-practices.md#bp-lambda-serviceexception) en *Prácticas recomendadas*. ** `States.ALL` ** Comodín que coincide con cualquier nombre de error conocido. El tipo de error `States.ALL` debe aparecer solo en un `Catcher` y no puede detectar el error del terminal `States.DataLimitExceeded` o los tipos de error `Runtime`. Para obtener más información, consulte [`States.DataLimitExceeded`](#error-data-limit-exceed) y [`States.Runtime`](#states-runtime-error). ** `States.DataLimitExceeded` ** Un error de terminal que el tipo de error `States.ALL` no puede detectar. Sin embargo, puedes capturarlo o volver a intentarlo `States.DataLimitExceeded` especificándolo explícitamente en el `ErrorEquals` campo de un `Retry` bloque `Catch` o. Notificación por una de las siguientes condiciones: + La salida de un conector supera la cuota de tamaño de carga útil. + La salida de un estado supera la cuota de tamaño de la carga útil. + Después del procesamiento de `Parameters`, la entrada de un estado es mayor que la cuota de tamaño de la carga útil. Para obtener más información sobre cuotas, consulte [Service Quotas de Step Functions](service-quotas.md). **`States.ExceedToleratedFailureThreshold`** Se produjo un error en un estado `Map` porque el número de elementos con errores superó el umbral especificado en la definición de la máquina de estado. Para obtener más información, consulte [Establecimiento de umbrales de error para los estados de los mapas distribuidos en Step Functions](state-map-distributed.md#maprun-fail-threshold). ** `States.HeartbeatTimeout` ** Estado `Task` que no puede enviar un latido durante un período mayor que el valor de `HeartbeatSeconds`. `HeartbeatTimeout` está disponible dentro de los campos `Catch` y `Retry`. ** `States.Http.Socket` ** Se produce cuando el tiempo de ejecución de una tarea HTTP es aproximadamente 60 segundos. Consulte [Cuotas relacionadas con la tarea HTTP](service-quotas.md#service-limits-http-task). **`States.ItemReaderFailed`** Se produjo un error en un estado `Map` porque no se pudo leer la fuente del elemento especificada en el campo `ItemReader`. Para obtener más información, consulte `ItemReader (Mapa)`. ** `States.Permissions` ** Un estado `Task` registró un error porque no tenía privilegios suficientes para ejecutar el código especificado. **`States.ResultWriterFailed`** Un estado `Map` no pudo escribir los resultados en el destino especificado en el campo `ResultWriter`. Para obtener más información, consulte `ResultWriter (Mapa)`. **`States.Runtime`** Error de ejecución causado por una excepción que no se ha podido procesar. La causa de estos problemas suelen ser errores en el tiempo de ejecución, como intentar aplicar `InputPath` o `OutputPath` a una carga JSON nula. Un error `States.Runtime` no se puede volver a intentar y siempre provocará que se produzca un error en la ejecución. Un reintento o captura de `States.ALL` no capturará los errores de `States.Runtime`. ** `States.TaskFailed` ** Estado `Task` que registró un error durante la ejecución. Cuando se usa en un reintento o una captura, `States.TaskFailed` actúa como un comodín que coincide con cualquier nombre de error conocido excepto `States.Timeout`. ** `States.Timeout` ** Se informa cuando un estado `Task` se ejecuta durante más tiempo que el valor `TimeoutSeconds` o no puede enviar un latido durante un período mayor que el valor `HeartbeatSeconds`. Si una *máquina de estado anidada* arroja un `States.Timeout`, la máquina principal recibirá un error `States.TaskedFailed`. También se informa de un error `States.Timeout` cuando la ejecución completa de una máquina de estado dura más tiempo que el valor `TimeoutSeconds` especificado. **nota** Históricamente, los errores no controlados en los tiempos de ejecución de Lambda solo se notificaban como `Lambda.Unknown`. En los tiempos de ejecución más recientes, los tiempos de espera se notifican como `Sandbox.Timedout` en la salida de error. Cuando Lambda supera el número máximo de invocaciones, el error notificado es `Lambda.TooManyRequestsException`. Haga coincidir `Lambda.Unknown`, `Sandbox.Timedout` y `States.TaskFailed` para gestionar posibles errores. También puede usar `States.ALL`, pero debe estar solo y al final de la lista. Para obtener más información sobre los errores de Lambda `Handled` y `Unhandled`, consulte `FunctionError` en la [Guía para desarrolladores de AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html#API_Invoke_ResponseSyntax). ## Reintento después de un error Los estados `Task`, `Parallel` y `Map` pueden tener un campo llamado `Retry`, cuyo valor debe ser una matriz de objetos denominados *reintentadores*. Cada reintentador representa un número determinado de reintentos, que normalmente aumentan en intervalos de tiempo. Cuando uno de estos estados informa de un error y hay un campo `Retry`, Step Functions escanea los reintentadores en el orden indicado en la matriz. Cuando el nombre del error aparece en el valor del campo `ErrorEquals` de un reintentador, la máquina de estado realiza reintentos tal como se define en el campo `Retry`. Si la ejecución de redriven se vuelve a realizar con un [Estado de un flujo de trabajo de tarea](state-task.md), un [Estado Parallel de un flujo de trabajo](state-parallel.md) o un [estado Map en línea](state-map-inline.md) para el que haya definido [reintentos](#error-handling-retrying-after-an-error), el recuento de reintentos para estos estados se restablecerá en 0 para permitir el número máximo de intentos en redrive. Para una ejecución redriven, puede realizar un seguimiento de los reintentos individuales de estos estados mediante la consola. Para obtener más información, consulta [Comportamiento de reintento de las ejecuciones redriven](redrive-executions.md#redrive-retry-behavior) en [Reinicio de ejecuciones de máquinas de estado con redrive en Step Functions](redrive-executions.md). Los reintentadores contienen los siguientes campos: ** `ErrorEquals` (Obligatorio)** Matriz no vacía de cadenas que coinciden con nombres de error. Cuando un estado registra un error, Step Functions lo analiza a través de los reintentadores. Cuando el nombre de error aparece en esta matriz, se implementa la política de reintentos que se describe en este reintentador. ** `IntervalSeconds` (opcional)** Un entero positivo que representa el número de segundos antes del primer intento de reintento (de forma `1` predeterminada). `IntervalSeconds`tiene un valor máximo de 99.999.999. ** `MaxAttempts` (opcional)** Entero positivo que representa el número máximo de reintentos (el valor predeterminado es `3`). Si el error se repite más veces de las especificadas, se interrumpen los reintentos y se reanuda el control normal de errores. Un valor de `0` especifica que el error no se volverá a intentar nunca. `MaxAttempts`tiene un valor máximo de 99.999.999. ** `BackoffRate` (opcional)** Multiplicador según el cual aumenta el intervalo de reintento que indica `IntervalSeconds` después de cada intento de reintento. De forma predeterminada, el `BackoffRate` valor aumenta en `2.0`. Por ejemplo, supongamos que `IntervalSeconds` es 3, `MaxAttempts` es 3 y `BackoffRate` es 2. El primer intento se realiza tres segundos después de que se produzca el error. El segundo reintento tiene lugar seis segundos después del primer intento. El tercer reintento tiene lugar 12 segundos después del segundo reintento. ** `MaxDelaySeconds` (opcional) ** Un entero positivo que establece el valor máximo, en segundos, hasta el que puede aumentar un intervalo de reintento. Es útil utilizar este campo con el campo `BackoffRate`. El valor que se especifica en este campo limita los tiempos de espera exponenciales resultantes del multiplicador de la tasa de regresión que se aplique a cada reintento consecutivo. Debe especificar un valor mayor que 0 y menor que 31622401 para `MaxDelaySeconds`. Si no especifica este valor, Step Functions no limitará los tiempos de espera entre reintentos. ** `JitterStrategy` (opcional) ** Cadena que determina si se debe incluir o no la fluctuación en los tiempos de espera entre reintentos consecutivos. La fluctuación reduce los reintentos simultáneos al distribuirlos en un intervalo de retardo aleatorio. Esta cadena acepta `FULL` o `NONE` como valores. El valor predeterminado es `NONE`. Por ejemplo, supongamos que ha establecido `MaxAttempts` como 3, `IntervalSeconds` como 2 y `BackoffRate` como 2. El primer intento se realiza dos segundos después de que se produzca el error. El segundo reintento tiene lugar cuatro segundos después del primer intento y el tercer reintento, ocho segundos después del segundo intento. Si se establece `JitterStrategy` como `FULL`, el primer intervalo de reintento se distribuye aleatoriamente entre 0 y 2 segundos, el segundo intervalo de reintento se distribuye aleatoriamente entre 0 y 4 segundos y el tercer intervalo de reintento se distribuye aleatoriamente entre 0 y 8 segundos. **nota** Los reintentos se tratan como transiciones de estado. Para obtener información sobre cómo las transiciones de estado afectan a la facturación, consulte [Precios de Step Functions](https://aws.amazon.com/step-functions/pricing/) ### Ejemplos de campo de reintento Esta sección incluye los siguientes ejemplos de código para `Retry`. + [Retry with BackoffRate](#retrybackoffrate) + [Retry with MaxDelaySeconds](#retrymaxdelayseconds) + [Retry all errors except States.Timeout](#retrytimeout) + [Complex retry scenario](#complexretryeg) **Ejemplo 1: Vuelva a intentarlo con BackoffRate** En el siguiente ejemplo de `Retry` se realizan dos reintentos; el primero se realiza tras una espera de tres segundos. Según lo que especifique `BackoffRate`, Step Functions aumenta el intervalo entre cada reintento hasta alcanzar el número máximo de reintentos. En el ejemplo siguiente, el segundo reintento comienza después de esperar tres segundos tras el primer reintento. ``` "Retry": [ { "ErrorEquals": [ "States.Timeout" ], "IntervalSeconds": 3, "MaxAttempts": 2, "BackoffRate": 1 } ] ``` **Ejemplo 2: Vuelva a intentarlo con MaxDelaySeconds** En el siguiente ejemplo, se realizan tres reintentos y se limita el tiempo de espera resultante de `BackoffRate` a 5 segundos. El primer reintento se realiza tras esperar tres segundos. El segundo y el tercer reintento se realizan después de esperar cinco segundos después del reintento anterior, debido al límite máximo de tiempo de espera establecido en `MaxDelaySeconds`. ``` "Retry": [ { "ErrorEquals": [ "States.Timeout" ], "IntervalSeconds": 3, "MaxAttempts": 3, "BackoffRate":2, "MaxDelaySeconds": 5, "JitterStrategy": "FULL" } ] ``` Sin `MaxDelaySeconds`, el segundo reintento tendría lugar seis segundos después del primer reintento y el tercer reintento tendría lugar 12 segundos después del segundo. **Ejemplo 3: Vuelva a intentar todos los errores excepto States.Timeout** El nombre reservado `States.ALL` que aparece en el campo `ErrorEquals` de un reintentador es un nombre comodín que coincide con cualquier nombre de error. Debe aparecer solo en la matriz `ErrorEquals` y debe aparecer en el último reintentador de la matriz `Retry`. El nombre `States.TaskFailed` también actúa como comodín y coincide con cualquier error excepto con `States.Timeout`. En el siguiente ejemplo de un campo `Retry`, se reintentan todos los errores excepto `States.Timeout`. ``` "Retry": [ { "ErrorEquals": [ "States.Timeout" ], "MaxAttempts": 0 }, { "ErrorEquals": [ "States.ALL" ] } ] ``` **Ejemplo 4: Escenario de reintento complejo** Los parámetros de un reintentador se aplican a todas las visitas que se realizan a dicho reintentador durante la ejecución de un único estado. Supongamos que tenemos el siguiente estado `Task`. ``` "X": { "Type": "Task", "Resource": "arn:aws:states:{{region}}:123456789012:task:X", "Next": "Y", "Retry": [ { "ErrorEquals": [ "ErrorA", "ErrorB" ], "IntervalSeconds": 1, "BackoffRate": 2.0, "MaxAttempts": 2 }, { "ErrorEquals": [ "ErrorC" ], "IntervalSeconds": 5 } ], "Catch": [ { "ErrorEquals": [ "States.ALL" ], "Next": "Z" } ] } ``` Esta tarea falla cuatro veces seguidas y devuelve estos nombres de error: `ErrorA`, `ErrorB`, `ErrorC` y `ErrorB`. Como resultado, se produce lo siguiente: + Los dos primeros errores coinciden con el primer reintentador y generan esperas de uno y dos segundos. + El tercer error coincide con el segundo reintentador y genera una espera de cinco segundos. + El cuarto error también coincide con el primer reintentador. Sin embargo, ya alcanzó su máximo de dos reintentos (`MaxAttempts`) para ese error en particular. Por lo tanto, ese recuperador falla y la ejecución redirige el flujo de trabajo al estado `Z` a través del campo `Catch`. ## Estados alternativos Los estados `Task`, `Map` y `Parallel` pueden tener un campo llamado `Catch`. El valor de este campo debe ser una matriz de objetos, denominados *receptores*. Un receptor contiene los siguientes campos. ** `ErrorEquals` (Obligatorio)** Matriz no vacía de cadenas que coinciden con nombres de error, especificados exactamente como se indicaron en el campo del mismo nombre del reintentador. ** `Next` (Obligatorio)** Cadena que debe coincidir exactamente con uno de los nombres de estado de la máquina de estado. ** `ResultPath` (JSONPath, opcional)** [Ruta](concepts-input-output-filtering.md) que determina qué entrada envía el receptor al estado especificado en el campo `Next`. Cuando un estado registra un error y no hay un campo `Retry` o los reintentos no son capaces de resolver el problema, Step Functions lo analiza a través de los receptores en el orden en que aparecen en la matriz. Cuando el nombre de error aparece en el valor del campo `ErrorEquals` de un receptor, la máquina de estado adopta el estado especificado en el campo `Next`. El nombre reservado `States.ALL` que aparece en el campo `ErrorEquals` de un receptor es un nombre comodín que coincide con cualquier nombre de error. Debe aparecer solo en la matriz `ErrorEquals` y debe aparecer en el último receptor de la matriz `Catch`. El nombre `States.TaskFailed` también actúa como comodín y coincide con cualquier error excepto con `States.Timeout`. En el siguiente ejemplo, el campo `Catch` cambia a un estado llamado `RecoveryState` cuando una función de Lambda genera una excepción Java no controlada. De lo contrario, el campo cambia al estado `EndState`. ``` "Catch": [ { "ErrorEquals": [ "java.lang.Exception" ], "ResultPath": "$.error-info", "Next": "RecoveryState" }, { "ErrorEquals": [ "States.ALL" ], "Next": "EndState" } ] ``` **¿Cuántos errores puede capturar un receptor?** Cada receptor puede especificar **varios errores** que deben controlarse. ### Salida de error Cuando Step Functions adopta el estado especificado en un nombre catch, por lo general, el objeto contiene el campo `Cause`. El valor de este campo es una descripción del error en lenguaje natural. Este objeto se conoce como *salida de error*. En el ejemplo anterior de JSONPath, el primer receptor contiene un campo. `ResultPath`. Funciona de manera parecida a un campo `ResultPath` del nivel superior del estado, lo que genera dos posibilidades: + Toma los resultados de la ejecución de ese estado y los sobrescribe todos los datos de entrada del estado o parte de ellos. + Toma los resultados y los agrega a los datos de entrada. En el caso de los errores controlados por un receptor, el resultado de la ejecución del estado es la salida de error. Por tanto, en el primer receptor del ejemplo, el receptor agrega la salida de error a la entrada como un campo llamado `error-info` si no hay ningún campo con este nombre en los datos de entrada. A continuación, el receptor envía la entrada completa a `RecoveryState`. En el segundo receptor, la salida de error sobrescribe la entrada y el receptor solo envía la salida de error a `EndState`. Para flujos de trabajo de JSONPath, si no se especifica el campo `ResultPath`, este se establece de forma predeterminada en `$`, que selecciona y sobrescribe toda la entrada. Cuando un estado tiene tanto campo `Retry` como `Catch`, Step Functions utiliza primero los recuperadores adecuados. Si la política de reintentos no resuelve el error, Step Functions aplica la transición del receptor correspondiente. ### Provoca cargas útiles e integraciones de servicios Un receptor devuelve una carga de cadenas como salida. Cuando trabaje con integraciones de servicios como Amazon Athena AWS CodeBuild o, puede que desee convertir `Cause` la cadena a JSON. El siguiente ejemplo de un estado `Pass` con funciones intrínsecas muestra cómo convertir una cadena `Cause` a JSON. ``` "Handle escaped JSON with JSONtoString": { "Type": "Pass", "Parameters": { "Cause.$": "States.StringToJson($.Cause)" }, "Next": "Pass State with Pass Processing" }, ``` ## Ejemplos de máquina de estado que usan Retry y Catch Las máquinas de estado que se definen en los ejemplos siguientes presuponen la existencia de dos funciones de Lambda: una que siempre registra errores y otra que espera lo suficiente para permitir que transcurra el tiempo de espera especificado en la máquina de estado. Esta es una definición de una función Node.js Lambda que siempre falla y devuelve el mensaje. `error` En los ejemplos de máquinas de estado siguientes, esta función de Lambda se llama `FailFunction`. Para obtener más información sobre la creación de una función de Lambda, consulte [Paso 1: Crear una función de Lambda](tutorial-creating-lambda-state-machine.md#create-lambda-function). ``` exports.handler = (event, context, callback) => { callback("error"); }; ``` Esta es una definición de una función Node.js Lambda que permanece en reposo durante 10 segundos. En los ejemplos de máquinas de estado siguientes, esta función de Lambda se llama `sleep10`. ``` exports.handler = (event, context, callback) => { setTimeout(function(){ }, 11000); }; ``` **Configuración del tiempo de espera de la función** Cuando cree la función de Lambda para los ejemplos, recuerde establecer el valor `Timeout` en la configuración avanzada en 11 segundos. ### Control de errores con Retry Esta máquina de estado utiliza un campo `Retry` para recuperar una función que no se ejecuta correctamente y que devuelve el nombre de error `HandledError`. La función se reintenta dos veces, con un retroceso exponencial entre los reintentos. ``` { "Comment": "A Hello World example invoking Lambda function", "StartAt": "HelloWorld", "States": { "HelloWorld": { "Type": "Task", "Resource": "arn:aws:lambda:{{region}}:123456789012:function:FailFunction", "Retry": [ { "ErrorEquals": ["HandledError"], "IntervalSeconds": 1, "MaxAttempts": 2, "BackoffRate": 2.0 } ], "End": true } } } ``` Esta variante utiliza el código de error predefinido `States.TaskFailed`, que coincide con cualquier error que una función de Lambda pueda devolver. ``` { "Comment": "Hello World example which invokes a AWS Lambda function", "StartAt": "HelloWorld", "States": { "HelloWorld": { "Type": "Task", "Resource": "arn:aws:lambda:{{region}}:123456789012:function:FailFunction", "Retry": [ { "ErrorEquals": ["States.TaskFailed"], "IntervalSeconds": 1, "MaxAttempts": 2, "BackoffRate": 2.0 } ], "End": true } } } ``` **Prácticas recomendadas para gestionar las excepciones de Lambda** Las tareas que hacen referencia a una función de Lambda deben controlar las excepciones del servicio de Lambda. Para obtener más información, consulte [Gestionar excepciones transitorias del servicio de Lambda](sfn-best-practices.md#bp-lambda-serviceexception) en las Prácticas recomendadas. ### Control de errores con Catch En este ejemplo se utiliza un campo `Catch`. Cuando una función de Lambda devuelve un error, se recibe el error y la máquina de estado adopta el estado `fallback`. ``` { "Comment": "Hello World example which invokes a AWS Lambda function", "StartAt": "HelloWorld", "States": { "HelloWorld": { "Type": "Task", "Resource": "arn:aws:lambda:{{region}}:123456789012:function:FailFunction", "Catch": [ { "ErrorEquals": ["HandledError"], "Next": "fallback" } ], "End": true }, "fallback": { "Type": "Pass", "Result": "Hello, AWS Step Functions!", "End": true } } } ``` Esta variante utiliza el código de error predefinido `States.TaskFailed`, que coincide con cualquier error que una función de Lambda pueda devolver. ``` { "Comment": "Hello World example which invokes a AWS Lambda function", "StartAt": "HelloWorld", "States": { "HelloWorld": { "Type": "Task", "Resource": "arn:aws:lambda:{{region}}:123456789012:function:FailFunction", "Catch": [ { "ErrorEquals": ["States.TaskFailed"], "Next": "fallback" } ], "End": true }, "fallback": { "Type": "Pass", "Result": "Hello, AWS Step Functions!", "End": true } } } ``` ### Control de tiempos de espera con Retry Esta máquina de estado usa un campo `Retry` para reintentar un estado `Task` cuyo tiempo de espera se agota, en función del valor de tiempo de espera especificado en `TimeoutSeconds`. Step Functions vuelve a intentar la invocación de la función de Lambda en este estado `Task` dos veces, con un retroceso exponencial entre reintentos. ``` { "Comment": "Hello World example which invokes a AWS Lambda function", "StartAt": "HelloWorld", "States": { "HelloWorld": { "Type": "Task", "Resource": "arn:aws:lambda:{{region}}:123456789012:function:sleep10", "TimeoutSeconds": 2, "Retry": [ { "ErrorEquals": ["States.Timeout"], "IntervalSeconds": 1, "MaxAttempts": 2, "BackoffRate": 2.0 } ], "End": true } } } ``` ### Control de tiempos de espera con Catch En este ejemplo se utiliza un campo `Catch`. Cuando se agota un tiempo de espera, la maquina de estado adopta el estado `fallback`. ``` { "Comment": "Hello World example which invokes a AWS Lambda function", "StartAt": "HelloWorld", "States": { "HelloWorld": { "Type": "Task", "Resource": "arn:aws:lambda:{{region}}:123456789012:function:sleep10", "TimeoutSeconds": 2, "Catch": [ { "ErrorEquals": ["States.Timeout"], "Next": "fallback" } ], "End": true }, "fallback": { "Type": "Pass", "Result": "Hello, AWS Step Functions!", "End": true } } } ``` **Conservación de la entrada de estado y el error en JSONPath** En JSONPath, puede conservar la entrada del estado y el error utilizando `ResultPath`. Consulte [Se utiliza ResultPath para incluir tanto el error como la entrada en un `Catch`](input-output-resultpath.md#input-output-resultpath-catch).