Винятки у задачах «fire-and-forget»

1. Що таке «fire-and-forget»?

У програмуванні термін fire-and-forget означає запуск задачі без очікування її завершення. У світі C# і .NET це зазвичай роблять із задачами Task: їх запускають, ніде не очікують (await), не зберігають посилання — і фактично забувають.

// Кнопка запускає задачу у фоні, але її ніде не очікують (await).
button.Click += (s, e) =>
{
    Task.Run(() => ДовгаОперація());
};

Звучить привабливо: «хай працює у фоні, а я займуся своїм». Та за такого підходу, якщо всередині задачі станеться виняток, про нього ніхто вчасно не дізнається — він тихо загубиться.

2. Як працює обробка винятків у Task

Класика: await і обробка помилок

Стандартний спосіб працювати з асинхронними задачами — через await. Якщо в задачі сталася помилка, її буде викинуто в точці очікування:

try
{
    await SomeOperationAsync(); // якщо всередині виникне Exception, він потрапить у catch
}
catch(Exception ex)
{
    Console.WriteLine("Упс! У задачі сталася помилка: " + ex.Message);
}

Тобто коли ви очікуєте завершення задачі, ви не пропустите виняток.

Але задачі «fire-and-forget» ніхто не очікує!

public void ЗапуститиБезОчікування()
{
    // Задача сама по собі. Її ніхто не очікує...
    Task.Run(() => {
        // Десь усередині стається біда:
        throw new InvalidOperationException("Ой, усе пропало!");
    });
    // Метод завершився, задача тихо працює у фоні.
}

Якщо всередині такої задачі станеться виняток, він не буде викинутий у головному потоці. Застосунок продовжить працювати, наче нічого й не сталося.

Важливо

У .NET задача з необробленим винятком переходить у стан Faulted. Але якщо ви її не чекаєте (await, .Result, .Wait() тощо), виняток ніхто не прочитає, і він не проявиться у коді, що викликає.

Що насправді відбувається «під капотом»?

У задач, які ніхто не очікує, лишається єдиний шанс бути поміченими — подія TaskScheduler.UnobservedTaskException. Вона спрацьовує, коли збирач сміття (GC) знаходить задачу з необробленим винятком. Та це стається не відразу і не там, де ви чекаєте, — покладатися на це не варто.

3. Демонстрація: помилка у fire-and-forget

// Приклад: запускаємо fire-and-forget-задачу прямо з Main
using System;
using System.Threading.Tasks;

class Program
{
    static void Main(string[] args)
    {
        FireAndForgetExample();

        Console.WriteLine("Головний потік продовжує працювати...");
        // Дамо задачі час завершитися
        Task.Delay(2000).Wait();
    }

    static void FireAndForgetExample()
    {
        Task.Run(() =>
        {
            Console.WriteLine("Fire-and-forget-задача стартувала!");
            Task.Delay(500).Wait();
            throw new InvalidOperationException("Помилка всередині fire-and-forget-задачі!");
        });
    }
}

Якщо запустити цей код, то… нічого особливого не станеться. Помилка трапиться, але програма про неї не дізнається. Іноді попередження можна побачити в Output Window IDE, та користувач нічого не дізнається.

Чому це небезпечно в реальних проєктах?

• Складні баги, які важко відтворити («іноді не працює — незрозуміло чому»).
• Тиха втрата даних або логіки (наприклад, лист клієнтові не надіслано).
• У продакшені — відсутність сигналів про проблеми, якщо не налаштовано логування.

4. Коректні способи обробки помилок у fire-and-forget

Логування та обробка помилок усередині самої задачі

Мінімальний безпечний варіант — ловити винятки просто всередині fire-and-forget-задачі:

Task.Run(() =>
{
    try
    {
        // Ваш довгий/небезпечний код
        throw new InvalidOperationException("Щось пішло не так!");
    }
    catch (Exception ex)
    {
        // Логуємо помилку або інформуємо користувача
        Console.WriteLine("Fire-and-forget: спіймано виняток: " + ex.Message);
        // Можна писати в log-файл, використовувати систему алертів тощо.
    }
});

Асинхронні void-методи (і чому так робити не варто)

async void DangerousFireAndForget()
{
    // Щось небезпечне
    throw new Exception("Бабах!");
}

Методи async void по суті — fire-and-forget: їх неможливо почекати, вони не повертають Task. Винятки з них летять у глобальний обробник застосунку (наприклад, AppDomain.UnhandledException) і нерідко призводять до падіння процесу. Використовуйте async void лише для обробників подій — і то обережно.

Використання допоміжних методів для обробки помилок

Зручно винести безпечний запуск fire-and-forget в окрему обгортку:

// Універсальний метод для безпечного запуску fire-and-forget
public static void RunSafeFireAndForget(Func<Task> taskFactory)
{
    Task.Run(async () =>
    {
        try
        {
            await taskFactory();
        }
        catch (Exception ex)
        {
            // Логуємо виняток
            Console.WriteLine("Fire-and-forget (safe): " + ex);
            // Можна додати відправку в систему моніторингу!
        }
    });
}

// Використання:
RunSafeFireAndForget(async () =>
{
    await Task.Delay(1000);
    throw new InvalidOperationException("Всередині fire-and-forget!");
});

Приклад із «реального життя»: надсилання email

// Кнопка надсилання листа:
private void buttonSend_Click(object sender, EventArgs e)
{
    Task.Run(() => SendEmail());
}

// Метод надсилання:
private void SendEmail()
{
    try
    {
        // Тут може бути реальне надсилання
        throw new Exception("SMTP-сервер недоступний!");
    }
    catch (Exception ex)
    {
        // Логування
        File.AppendAllText("errors.log", $"Помилка надсилання: {ex.Message}\n");
    }
}

5. А що з UnobservedTaskException?

Як крайній захід, .NET надає подію TaskScheduler.UnobservedTaskException. Вона спрацьовує, якщо задача завершилася з помилкою, ніхто її не почекав, і об’єкт задачі було зібрано GC. Покладатися на це не варто — це механізм «останнього шансу».

TaskScheduler.UnobservedTaskException += (sender, e) =>
{
    Console.WriteLine("Глобальний UnobservedTaskException: " + e.Exception);
    e.SetObserved(); // Не забудьте це викликати, інакше застосунок може завершитися аварійно!
};

Детальніше: TaskScheduler.UnobservedTaskException.

6. Корисні нюанси

Схематичне порівняння підходів

await

Як правильно проєктувати fire-and-forget

• Якщо результат або стан задачі критичні — не робіть fire-and-forget. Використовуйте await або зберігайте Task для подальшого очікування.
• Fire-and-forget виправданий лише для справді неважливих фонових задач (наприклад, відправка телеметрії).
• Завжди обгортайте fire-and-forget у власний метод і ловіть/логуйте винятки.
• Для складних фонових сценаріїв використовуйте черги та воркери: Hangfire, Quartz.NET.

Практичне застосування та співбесіди

На співбесідах часто питають: «Що буде, якщо у fire-and-forget задачі станеться виняток?» або «Чому не можна всюди використовувати async void?» Правильна відповідь: тільки ви відповідаєте за долю помилок у фонових задачах — або ловите, логуєте й аналізуєте, або отримуєте баги-привиди.

Порівняння «fire-and-forget» і await

У наступній лекції обговоримо обробку помилок у паралельних задачах, що повертають кілька результатів. А поки пам’ятайте: якщо ви кудись «вистрілили», не забудьте перевірити, чи долетіло до цілі!

7. Типові помилки під час роботи з fire-and-forget-задачами

Помилка №1: Ігнорування винятків у fire-and-forget.
Новачки сподіваються, що винятки «десь спливуть». Без try-catch і логування вони губляться, призводячи до невиявлених багів.

Помилка №2: Використання async void поза обробниками подій.
Такі методи викидають винятки у глобальний обробник (наприклад, AppDomain.UnhandledException), що може завершити застосунок аварійно.

Помилка №3: Надмірна обробка винятків.
Ловити всі винятки всередині задачі може приховати проблеми, які краще обробляти в коді, що викликає, ускладнюючи налагодження.

Помилка №4: Зневага до логування.
Без логування помилок у fire-and-forget задачах неможливо дізнатися про збої, особливо у продакшені.