Provocar un error de forma controlada: alternativas históricas a Throw
Nota de alcance: reconstrucción editorial basada en la documentación oficial, capturada el 2026-05-16. Describe esa versión histórica; no acredita funciones, límites ni disponibilidad actuales. Consulta la fuente vigente antes de configurar un flujo nuevo.
La captura de la documentación indicaba que Make no ofrecía una directiva de manejo de errores llamada Throw y explicaba soluciones alternativas. Esa afirmación corresponde a la fecha de captura, no a una comprobación de disponibilidad actual.
Estas técnicas permiten representar como error una condición de negocio, por ejemplo que un registro todavía no exista. Si basta con no continuar, un filtro suele expresar mejor la intención que provocar un fallo.
Alternativa con Parse JSON
La primera opción consiste en configurar JSON > Parse JSON para que falle deliberadamente cuando se cumpla una condición. La fuente muestra este patrón con un error de validación. No debe confundirse con un módulo Throw nativo.
Añade una ruta de error al módulo y elige el resultado que necesitas:
| Manejador | Intención descrita |
|---|---|
| Rollback | Detener la ejecución y solicitar la reversión de las operaciones compatibles |
| Commit | Detener la ejecución confirmando las operaciones |
| Ignore | Dejar de procesar el paquete afectado |
| Break | Conservar el trabajo incompleto para resolverlo después |
Rollback no deshace acciones de módulos que no admiten reversión. Antes de introducir un error artificial, prueba la ruta con datos de prueba y comprueba qué se conserva.
Alternativa con dos escenarios y HTTP
El segundo patrón de la fuente busca un usuario en Zendesk y permite reintentar si todavía no aparece.
Escenario que llama:
- Usa HTTP > Make a request para llamar a la URL del webhook del segundo escenario.
- Envía como parámetro el correo u otro dato de búsqueda.
- Configura el módulo para tratar las respuestas HTTP de error como fallos; el nombre exacto del ajuste depende de la versión del módulo.
- Añade Break y configura la conservación y posterior resolución de la ejecución incompleta.
Escenario que responde:
- Recibe la solicitud mediante Webhooks > Custom webhook.
- Busca el usuario con Zendesk > Search for a User, usando el parámetro recibido.
- Activa la continuación de la ruta aunque la búsqueda no devuelva resultados.
- Usa un Router para separar «encontrado» y «no encontrado».
- Responde mediante Webhook response con una respuesta de éxito en el primer caso y una respuesta de error en el segundo.
No basta con que la búsqueda devuelva cero registros: la respuesta debe comunicar el fallo al escenario que llama. Mantén privada la URL del webhook.
Validación y límites
Prueba un usuario existente y otro inexistente. Revisa que solo el segundo entre en la ruta de error y que el reintento no duplique acciones anteriores. Un registro ausente de forma permanente necesita intervención, no reintentos sin límite. Consulta la guía oficial enlazada antes de adoptar este patrón histórico en una automatización nueva.