Почему (за счет чего) исключение внутри Task не рушит приложение?

@V0fka · Регистрация: 24.05.2010

Author24 — интернет-сервис помощи студентам

Привет!

Есть метод, который выбрасывает исключение:

C#

static void Process()
{
    throw new Exception();
}

Если вызвать этот метод в потоке из пула явно:

C#

ThreadPool.QueueUserWorkItem(state =>
{
    Process();
});

приложение падает.

Если вызвать этот метод через задачу:

C#

Task.Run(() =>
{
    Process();
});

приложение не падает.

Но Task вроде как использует потоки из пула потоков. Как объекту Task удается перехватить исключение и не ронять приложение?

@sau · 27.02.2019, 19:09

Сообщение от V0fka

Но Task вроде как использует потоки из пула потоков. Как объекту Task удается перехватить исключение и не ронять приложение?

Нормальное поведение - когда второстепенные потоки не роняют главный ,
просто QueueUserWorkItem чуть поумнее и пробрасывает исключение в вызывающий поток , видимо из-за того , что Вы сами поток не создаете и не контролируете его работу.

@TopLayer · 27.02.2019, 20:06

Сообщение от V0fka

Как объекту Task удается перехватить исключение и не ронять приложение?

Про try/catch слышали?

@Usaga · 28.02.2019, 06:57

V0fka, это потому, что Task как раз и поумнее. Делегат переданный в Task исполняется в своём try\catch, что не даёт "завалить" поток с необработанным исключением и, соответственно, возбудиться на это CLR.

Когда в потоке в Task происходит исключение, оно перехватывается и заворачивается в AggregateException, которое сохраняется в свойстве Exception самой задачи, откуда его потом можно прочитать или явно, или через Task.Wait, или через await.

Это одна из причин, почему Microsoft настоятельно рекомендует забыть про старые классы Thread и использовать только Task.

@V0fka · 28.02.2019, 10:43 **[ТС]**

Сообщение от sau

Нормальное поведение - когда второстепенные потоки не роняют главный ,
просто QueueUserWorkItem чуть поумнее и пробрасывает исключение в вызывающий поток , видимо из-за того , что Вы сами поток не создаете и не контролируете его работу.

Так QueueUserWorkItem как раз и роняет приложение.

Сообщение от TopLayer

Про try/catch слышали?

Слышал. Но если обернуть

C#

ThreadPool.QueueUserWorkItem(state =>
{
    Process();
});

в try\catch - ситуация не меняется.

Usaga, я просто думал, что внутри Task используется именно ThreadPool.QueueUserWorkItem, который независимо от try\catch все равно валит приложение. Я думал неправильно?

@Usaga · 28.02.2019, 10:51

Сообщение от V0fka

в try\catch - ситуация не меняется.

И не изменится. try\catch только в одном потоке работает, и исполнение кода из этого блока (где ThreadPool) уже вышло.

Сообщение от V0fka

Я думал неправильно?

Да. Не правильно. Что Task, что ThreadPool - оба используют средства ОС. Они друг друга не переиспользуют. Т.е. Task это прямо новая реализация механизмов работы с потоками.

@V0fka · 28.02.2019, 11:15 **[ТС]**

Usaga, ясно, спасибо!

@TopLayer · 28.02.2019, 22:28

Сообщение от V0fka

Слышал. Но если обернуть

C#

ThreadPool.QueueUserWorkItem(state =>
{
    Process();
});

в try\catch - ситуация не меняется.

Там принцип заворачивания другой:

C#

ThreadPool.QueueUserWorkItem(state =>
{
    try
    {
        Process();
    }
    catch (Exception e)
    {
        // сохранить e для будущего использования
    }
});

@V0fka · 01.03.2019, 09:41 **[ТС]**

Сообщение от TopLayer

Там принцип заворачивания другой

Не подумал, что можно завернуть так

, спасибо!

Но сейчас снова стало непонятно: в задачах таки используется ThreadPool.QueueUserWorkItem или там используется что-то другое (что в свою очередь или что около того используется так же внутри ThreadPool.QueueUserWorkItem)?

@Usaga · 01.03.2019, 10:47

V0fka, я выше написал: в Task полностью своя реализация.

Почему (за счет чего) исключение внутри Task не рушит приложение?

Решение

Решение

@sau 2734 / 2041 / 379 Регистрация: 22.07.2011 Сообщений: 7,731
	27.02.2019, 19:09	2
	Сообщение от V0fka Но Task вроде как использует потоки из пула потоков. Как объекту Task удается перехватить исключение и не ронять приложение? Нормальное поведение - когда второстепенные потоки не роняют главный , просто QueueUserWorkItem чуть поумнее и пробрасывает исключение в вызывающий поток , видимо из-за того , что Вы сами поток не создаете и не контролируете его работу. 0

@TopLayer 907 / 664 / 318 Регистрация: 23.10.2016 Сообщений: 1,543
	27.02.2019, 20:06	3
	Сообщение от V0fka Как объекту Task удается перехватить исключение и не ронять приложение? Про try/catch слышали? 0

@Usaga 12089 / 8367 / 1280 Регистрация: 21.01.2016 Сообщений: 31,546
	28.02.2019, 06:57	4
	V0fka, это потому, что `Task` как раз и поумнее. Делегат переданный в `Task` исполняется в своём `try\catch`, что не даёт "завалить" поток с необработанным исключением и, соответственно, возбудиться на это `CLR`. Когда в потоке в `Task` происходит исключение, оно перехватывается и заворачивается в AggregateException, которое сохраняется в свойстве Exception самой задачи, откуда его потом можно прочитать или явно, или через `Task.Wait`, или через `await`. Это одна из причин, почему Microsoft настоятельно рекомендует забыть про старые классы `Thread` и использовать только `Task`. 2

@Usaga 12089 / 8367 / 1280 Регистрация: 21.01.2016 Сообщений: 31,546
	28.02.2019, 10:51	6
	Сообщение было отмечено V0fka как решение Решение Сообщение от V0fka в try\catch - ситуация не меняется. И не изменится. try\catch только в одном потоке работает, и исполнение кода из этого блока (где ThreadPool) уже вышло. Сообщение от V0fka Я думал неправильно? Да. Не правильно. Что Task, что ThreadPool - оба используют средства ОС. Они друг друга не переиспользуют. Т.е. Task это прямо новая реализация механизмов работы с потоками. 1

@V0fka 86 / 13 / 1 Регистрация: 24.05.2010 Сообщений: 590
	28.02.2019, 11:15 [ТС]	7
	Usaga, ясно, спасибо! 0

@V0fka 86 / 13 / 1 Регистрация: 24.05.2010 Сообщений: 590
	01.03.2019, 09:41 [ТС]	9
	Сообщение от TopLayer Там принцип заворачивания другой Не подумал, что можно завернуть так , спасибо! Но сейчас снова стало непонятно: в задачах таки используется ThreadPool.QueueUserWorkItem или там используется что-то другое (что в свою очередь или что около того используется так же внутри ThreadPool.QueueUserWorkItem)? 0

@Usaga 12089 / 8367 / 1280 Регистрация: 21.01.2016 Сообщений: 31,546
	01.03.2019, 10:47	10
	V0fka, я выше написал: в Task полностью своя реализация. 1

Опции темы