Try / Catch

Try / Catch

Tipo: try-catch  ·  Paquete: Core Activities v1.0.8

Ejecuta un bloque de actividades y, si alguna falla, en vez de detener toda la ejecución, salta a un bloque alternativo donde puedes reaccionar: registrar el error, notificar, o seguir un plan B. Es la herramienta clave para que tu automatización sea robusta ante los problemas que sabes que pueden ocurrir (una página que no carga, un archivo que no existe, un sistema que a veces falla).

Tiene tres bloques: try (lo que intentas), catch (qué hacer si falla) y finally (lo que se ejecuta siempre, pase lo que pase).

Cómo funciona

1. Ejecuta las actividades de try.
2. Si todas tienen éxito, omite el catch.
3. Si alguna falla, detiene el try en ese punto, guarda el error en errorVariable (si la definiste) —un objeto ZoanError con el detalle de la excepción— y ejecuta el bloque catch.
4. Al final, siempre ejecuta finally —tanto si hubo error como si no— ideal para liberar recursos (cerrar un navegador, una conexión).

Tras el catch, la ejecución continúa normalmente con lo que venga después del Try/Catch: el error quedó “atrapado”. Detalles que conviene saber:

• Un catch vacío también atrapa el error: el flujo sigue como si nada. Úsalo solo si de verdad quieres ignorar el fallo, y deja al menos un Log.
• Un error dentro del catch o del finally no lo atrapa este mismo Try/Catch: sube al siguiente que lo contenga, o hace fallar la ejecución.
• Para volver a lanzar el error después de registrarlo, usa Throw con message = error.Message y errorType = error.Type.

Parámetros requeridos

Ninguno. (El único bloque obligatorio es el sub-flujo try.)

Parámetros opcionales

Parámetro	Tipo	Por defecto	Descripción
errorVariable	string	—	Nombre de la variable que recibe el error capturado, de tipo ZoanError. En el catch accede a .Message, .Type, .Source y .StackTrace. No hace falta declararla; si la declaraste como texto (string), recibe solo el mensaje.

Sub-flujos

try requerido

Actividades a intentar. Si una falla, el resto del try no se ejecuta.

catch opcional

Actividades que se ejecutan solo si algo en el try falló.

finally opcional

Actividades que se ejecutan siempre, haya fallado o no el try. También si alguien termina la ejecución (Terminar en Zoan Cloud, el Designer o el Agent): el finally tiene 10 segundos para cerrar lo abierto, así que es el lugar para cerrar la aplicación o el navegador. Si no alcanza a terminar en ese tiempo, queda una advertencia en el log y la ejecución termina igual.

Salida

Esta actividad no devuelve ningún valor. El error capturado queda en la variable de errorVariable:

Propiedad	Contenido
.Message	El mensaje del error.
.Type	El tipo: el errorType de un Throw (PlaybookException por defecto, BusinessRuleException para errores de negocio) o el nombre de la excepción del sistema (TimeoutException, HttpRequestException…).
.Source	El componente donde se originó.
.StackTrace	La traza, para diagnóstico.

Si el error viene de un playbook o proceso invocado, ZoanError muestra el error original, no el envoltorio de la invocación.

Ejemplo

Intentar leer un Excel; si falla, registrar el error y seguir; y cerrar el libro pase lo que pase:

Try / Catch   errorVariable = error
 ├─ try:
 │    Excel Open        path = asset("datos.xlsx")   → output: libro
 │    Excel Read Range  excel = libro   range = "A1:D100"   → output: tabla
 ├─ catch:
 │    Log   level = error   message = "No se pudo leer el Excel (" + error.Type + "): " + error.Message
 │    Set Variable   name = tabla   value = newDataTable()    // valor por defecto
 └─ finally:
      Excel Close   excel = libro

errorVariable es un objeto ZoanError

Tratarla como texto sigue funcionando: error o "Error: " + error usan el mensaje, así que los playbooks que ya la leían como string no se rompen. Usa error.Type para distinguir errores y ramificar el catch.

Try/Catch vs Retry

• Usa Try / Catch cuando quieres manejar un error y continuar con un plan alternativo.
• Usa Retry cuando el error es transitorio (una web lenta, la red) y basta con volver a intentar la misma acción.

Puedes combinarlos: un Retry dentro de un Try/Catch reintenta primero y, si aun así falla, el catch maneja la situación.

Cancelaciones y break/continue no son errores

Si terminas la ejecución desde el portal, o usas Break/Continue dentro del try, no se tratan como errores: el catch no se dispara. El finally, en cambio, sí se ejecuta.

Los tiempos de espera sí son errores

Cuando una actividad se queda sin tiempo por su cuenta (un servicio web que no responde, una aplicación que no contesta, el timeout de la propia actividad), falla con un error normal de tipo TimeoutException que el catch captura y Retry reintenta. El mensaje nombra la actividad. Solo terminar la ejecución, o el tope de duración del playbook, siguen siendo cancelaciones. Desde la versión 1.2.29.

Errores comunes

Mensaje	Causa y solución
El bloque Finally no terminó después de que se terminó la ejecución: …	Advertencia: se terminó la ejecución y el finally no acabó en 10 segundos (o falló). Deja en el finally solo cierres rápidos.
El error se «pierde»	El catch está vacío y no hay errorVariable: el fallo queda atrapado sin rastro. Registra el error con un Log o vuelve a lanzarlo con Throw.

Actividades relacionadas

• Retry — reintentar automáticamente un bloque que falla.
• Throw — lanzar un error a propósito (que un Try/Catch externo puede capturar).
• Log — registrar el error capturado en el catch.