Error

Error — це блок, який використовується для примусової зупинки виконання флоу та виводу повідомлення про помилку. Це стоп вашої інтеграції: як тільки логіка доходить до цього блоку, робота припиняється, а користувач отримує чітке пояснення того, що пішло не так.
Блок не виконує перевірки самостійно — він фіксує та повертає повідомлення про помилку, яке було сформоване логікою інших блоків (найчастіше IF, HTTP Request, Loop).
Навігація
- Призначення та доступність
- Налаштування блоку
- Робота в Request Error Flow (зв'язок з IF)
- Робота з масивами помилок (Loop)
- FAQ
Призначення та доступність
─────────────────────────────────────────────────────────────-
Блок Error є універсальним інструментом. На відміну від валідації акаунта, яка працює лише на старті, цей блок можна використовувати для обробки помилок на будь-якому етапі роботи.
Де можна використовувати блок:
- Authentication / Account Validation / Request Error Flow: для обробки проблем із доступами або некоректних відповідей API.
- Main Action / Input / Output: для зупинки процесу, якщо отримані дані не відповідають бізнес-логіці.
- Custom Flows: у будь-яких допоміжних потоках.
Найчастіше блок стає центром логіки у Request Error Flow, де система аналізує "погані" відповіді від сервера (4xx, 5xx) і перетворює їх на зрозумілі людською мовою повідомлення.
Фактично Request Error Flow + IF + Error — це стандартний патерн обробки помилок у платформі.
Налаштування блоку
─────────────────────────────────────────────────────────────-
Блок максимально зосереджений на одному завданні — передати інформацію про проблему.

1 -> Message: текст помилки, який побачить кінцевий користувач. Можна ввести статичний текст (наприклад: "Invalid API key"), або вставити динамічну змінну (наприклад, error.message з відповіді API).
2 -> Перемикач режиму полів TXT / EXP: поле підтримує перемикання між простим текстом та виразами.
Простий варіант (TXT режим) - все обробляється як текст.
Просунутий варіант (EXP режим) - вміст обробляється як повноцінний вираз (Expression). Дозволяє застосувати логічні оператори та функції безпосередньо в полі вибору. Наприклад, «/» у режимі TXT - це роздільник, а в режимі EXP - ділення.
Робота в Request Error Flow (зв'язок з IF)
─────────────────────────────────────────────────────────────-
Найефективніше блок Error працює у зв'язці з блоком IF. Це дозволяє створити багаторівневу логічну систему обробки помилок.
Типова логіка:
1 -> Request Error Flow: перехоплює помилку запиту.
2 -> IF : перевіряє наявність поля error. Кожна гілка відповідає конкретному типу помилки.
3 -> Гілка False: залишається порожня , якщо поле error не існує (це означає що запит пройшов успішно)
4 -> Гілка True: веде до наступного блоку IF для додаткової перевірки.
5 -> IF : перевіряє на порожність вкладене поле з описом помилки.
6 -> Гілка False: веде до блоку Error із статичним повідомленням (наприклад: Unknown API error)
7 -> Гілка True: веде до блоку Error де формується відповідне повідомлення (наприклад змінна із відповіді API)

Робота з масивами помилок (Loop)
─────────────────────────────────────────────────────────────-
Іноді API повертає не одну помилку, а цілий список (масив) , наприклад, декілька полів заповнені не правильно. У таких випадках блок Error можна комбінувати з Object Builder та Loop.
1 -> Loop: проходить по масиву помилок errors із відповіді API.
2 -> Object Builder (всередині циклу): збирає всі помилки в один об'єкт (в змінну наприклад).
3 -> Error: вставляємо змінну в поле Message, вміст змінної побачить користувач при виникненні помилки.
На етапі Test ви побачите результат сформованої помилки.


FAQ
─────────────────────────────────────────────────────────────-
1. Чи обов'язково використовувати блок Error в Request Error Flow?
Так, якщо ви хочете, щоб користувач бачив кастомну помилку замість системного повідомлення платформи.
2. Що станеться з даними, якщо спрацював блок Error?
Виконання інтеграції негайно припиняється. Будь-які наступні блоки в цьому або батьківських флоу не будуть виконані. Дані не будуть передані в Output.
3. Чи можна використовувати кілька блоків Error в одному флоу?
Так. Це стандартна практика. Кожен блок Error може відповідати конкретному сценарію помилки.
4. Чи побачить користувач текст із поля Message?
Так. Саме цей текст буде відображений користувачу як причина помилки.
5. Чи можна використовувати Error поза Request Error Flow?
Так. Блок універсальний і може використовуватися у будь-якому флоу, де потрібно зафіксувати помилку.