Вопрос по .net, exception, asp.net, unhandled-exception, multithreading – Как лечить необработанные исключения потоков в ASP.NET?

8

How is an ASP.NET application supposed to deal with unhandled exceptions which are occuring on a non-request background thread (due to bugs)?

По умолчанию такие исключения приводят к завершению процесса.This is unacceptable in the setting of an ASP.NET worker process потому что одновременно выполняющиеся запросы прерываются непредсказуемо. Это также проблема производительности.

Исключения в потоке запросов не являются проблемой, поскольку ASP.NET обрабатывает их (показывая страницу с ошибкой).

AppDomain.UnhandledException событие позволяет наблюдать, что произошла исключительная ситуация, но в этой точке нельзя предотвратить завершение.

Вот репродукция, которую нужно вставить в кодовую страницу ASPX.

protected void Page_Load(object sender, EventArgs e)
{
    var thread = new Thread(() =>
        {
            throw new InvalidOperationException("some failure on a helper thread");
        });
    thread.Start();
    thread.Join();
}

Единственное известное мне решение состоит в том, чтобы никогда не позволять исключению & quot; бежать & quot; необработанный. Есть ли другое, более глобальное и основательное решение для этого?

У меня такая же проблема ... странно, что команда asp.net никогда не думала об этом. У меня есть модуль http третьей части, который в какой-то момент дает сбой и выдает исключения, которые заставляют рабочий процесс отображать & quot; Служба недоступна & quot; !!! Jalal El-Shaer

Ваш Ответ

3   ответа
0

legacyUnhandledExceptionPolicy & quot; вариант ваш ответ.

Unhandled exceptions causing ASP.NET to crash in .NET 2.0 ; http://blogs.msdn.com/b/tom/archive/2007/12/04/unhandled-exceptions-causing-asp-net-to-crash-in-net-2-0.aspx

Спасибо, но я особенно хочу избежать сбоев, и я не думаю, что включение устаревших настроек - это путь к будущему. usr
1

попробуйте рассмотреть вопрос об изменении структуры, которую вы используете в настоящее время, и заменить ее на Rx

http://msdn.microsoft.com/en-us/data/gg577609.aspx

Пакеты самородков:

https://nuget.org/packages/Rx-Main/1.0.11226

Это эквивалентный код Rx:

        var o = Observable.Start(() => { throw new NotImplementedException(); });

        o.Subscribe(
            onNext => { },
            onError => { },
            () => { Console.WriteLine("Operation done"); });

Как вы можете видеть, ошибка не выйдет из фонового потока при указанииhandler for the error, onError => { }

Если вы не укажете обработчик ошибок, исключение будет распространено:

        o.Subscribe(
            onNext => { },
            () => { Console.WriteLine("Operation done"); });

В приведенном выше примере исключение будет распространено и вызовет те же проблемы, что и опубликованный вами код.

Что ж, Rx - это гораздо больше, чем просто работа с потоком событий, это было главной целью, но фреймворк развивался и знает, что содержит богатый API для работы с асинхронными методами. Единственная причина, я бы не рекомендовал RxyetЕсли вы выполняете свои фоновые потоки параллельно, даже когда Rx предоставляет API для этого, я обнаружил, что лучше использоватьTask объект
Я делаю многопоточность в контексте, где я не имею дело с потоками событий. Не уверен, что Rx хорошо подходит здесь. usr
0

анного исключения. https://msdn.microsoft.com/en-us/library/system.windows.applicationunhandledexceptioneventargs.handled(v=vs.95)

Это должно предотвратить перезапуск рабочего процесса из-за ошибки в фоновом потоке.

Вы бы не сделали этого для всех исключений. Только те, кого ты знаешь, безопасно игнорировать.

Похожие вопросы