2009-07-10 3 views
2

Наши службы WCF иногда создают рабочий поток для обработки чего-то, чего не беспокоит клиент. Рабочие потоки не сообщают о статусе клиенту. Фактически, служба, возможно, уже вернула результаты клиенту к моменту окончания потока.Обработка исключений для резьбы в WCF

Одна из этих фоновых потоков недавно вызвала исключение. Исключение было необработанным, поэтому IIS разбился.

Я могу исправить это конкретное исключение, но в будущем кто-то может добавить код, который вызывает другое неожиданное исключение. Я хочу предотвратить это от сбоев IIS в будущем.

Я знаю, что приложения System.Windows.Forms могут обрабатывать исключения потоков, реализуя Application.ThreadException. Есть ли что-то подобное, что я могу сделать с помощью службы WCF? Или если Application.ThreadException - это путь, как бы подключить его к службе WCF?

В документации MSDN для AppDomain.UnhandledException указано, что это не предотвращает сбой. Документы для ServiceModel.AsynchronousThreadExceptionHandler предлагают только для потоков WCF.

Как минимум, я хотел бы захватить трассировку стека из исключения перед сбоем, но избежать будущих сбоев было бы идеально.

Опять же, позвольте мне подчеркнуть, что это не исключение, которое я хочу вернуть в качестве ошибки WCF для клиента.

ответ

1

Поскольку вы не знаете, что послужило причиной исключения, единственная разумная вещь - крах. Вы не представляете, в каком состоянии находится служба, и вы можете ухудшить ситуацию, продолжая.

Помните, что IIS перезапустит сервис для вас, очистит и предположительно работает.

+1

Скажите, пожалуйста, причину downvote. Ответы вряд ли улучшатся, не зная, что с ними не так. –

+0

Я согласен с этим ... если у вас есть ожидаемое исключение, вы должны обращаться с ним близко к его происхождению. Если это неожиданно, это должно привести к сбою приложения. –

+0

Наш код в рабочих потоках не будет делать ничего безумного, что оставило бы вещи в неизвестном состоянии. Если бы сам IIS не был взломан, я бы скорее не потерпел крушение. Я бы выбрал проблему и продолжаю ее перебирать. (Обратите внимание, что я ничего не проголосовал.) –

1

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

+0

Да, я надеюсь, что все будут обертывать методы потока с помощью try/catch высокого уровня. Как связать обработчик AppDomain.UnhandledException в службе WCF? –

+0

Вам нужно будет сделать это во время запуска домена. Это может быть что-то в вашем стартовом коде, если у вас есть собственный хост или в вашем Global.asax, если вы размещаете в IIS, например, в обычном asp.net-приложении. – tomasr

Смежные вопросы