Ответ 1
О, в Windows Forms вы определенно должны быть способны заставить его работать. Единственное, что вы должны следить за событиями, происходящими на разных потоках.
У меня есть старая статья Code Project, которая должна помочь:
Я поддерживаю приложение .NET 1.1, и одной из задач, которые мне поручены, является обеспечение того, чтобы пользователь не видел никаких недружественных уведомлений об ошибках.
Я добавил обработчики в Application.ThreadException
и AppDomain.CurrentDomain.UnhandledException
, которые действительно вызывают. Моя проблема в том, что стандартное диалоговое окно ошибки CLR по-прежнему отображается (до вызова обработчика исключений).
Джефф рассказывает об этой проблеме в своем блоге здесь и здесь. Но там нет решения. Так что же является стандартным способом в .NET 1.1 для обработки необработанных исключений и отображения удобного диалогового окна?
Ответ Джеффа был помечен как правильный ответ, поскольку предоставленная им ссылка содержит наиболее полную информацию о том, как сделать то, что требуется.
О, в Windows Forms вы определенно должны быть способны заставить его работать. Единственное, что вы должны следить за событиями, происходящими на разных потоках.
У меня есть старая статья Code Project, которая должна помочь:
AppDomain.UnhandledException - это событие, а не глобальный обработчик исключений. Это означает, что к моменту его создания ваше приложение уже отправляется в канализацию, и вы ничего не можете с этим поделать, за исключением очистки и регистрации ошибок.
То, что произошло за кулисами, таково: инфраструктура обнаружила исключение, подошла к стеку вызовов до самого верха, не обнаружила обработчиков, которые бы восстановились после ошибки, поэтому не смогли определить, было ли безопасно продолжать выполнение. Таким образом, он запустил последовательность выключения и включил это событие в качестве любезности для вас, чтобы вы могли отдать должное своему уже обреченному процессу. Это происходит, когда исключение остается необработанным в основном потоке.
Не существует одноточечного решения этой ошибки. Вам нужно поставить реальный обработчик исключений (блок catch) вверх по течению от всех мест, где возникает эта ошибка, и перенаправить его (например) на метод/класс глобального обработчика, который будет определять, безопасно ли просто сообщать и продолжать, на основе тип исключения и/или контент.
Изменить: можно отключить (= взломать) механизм отчетности об ошибках, встроенный в Windows, поэтому обязательное диалоговое окно "сбой и запись" не отображается, когда ваше приложение опускается. Однако это становится эффективным для всех приложений в системе, а не только для ваших собственных.
Необработанное поведение исключения в приложении .NET 1.x Windows Forms зависит от:
По умолчанию необработанные исключения:
Точками контакта для необработанного исключения являются:
Встроенная обработка исключений Windows Form делает по умолчанию следующее:
Вы можете отключить последнее поведение, установив jitDebugging = true в App.Config. Но помните, что это может быть ваш последний шанс прекратить действие приложения. Таким образом, следующим шагом, чтобы поймать необработанное исключение, является регистрация для события Application.ThreadException, например:
Application.ThreadException += new
Threading.ThreadExceptionHandler(CatchFormsExceptions);
Обратите внимание на параметр реестра DbgJitDebugLaunchSetting в разделе HKEY_LOCAL_MACHINE\Software.NetFramework. Это одно из трех значений, о которых я знаю:
В Visual Studio перейдите в меню "Инструменты" → "Параметры" → "Отладка → JIT", чтобы установить этот ключ в 0 или 2. Но значение 1 обычно лучше всего подходит для конечного пользователя. Обратите внимание, что этот раздел реестра действует до события незавершенного исключения CLR.
Это последнее событие - ваш последний шанс зарегистрировать необработанное исключение. Он срабатывает до того, как ваши блоки finally завершатся. Вы можете перехватить это событие следующим образом:
AppDomain.CurrentDomain.UnhandledException += new
System.UnhandledExceptionEventHandler(CatchClrExceptions);
Это консольное приложение или приложение Windows Forms? Если это консольное приложение .NET 1.1, это, к сожалению, задумано - это подтверждается разработчиком MSFT во втором сообщении в блоге, на которое вы ссылались:
Кстати, на моей машине 1.1 пример из MSDN имеет ожидаемый результат; просто вторая строка не появляется, пока вы не подключите отладчик (или нет). В v2 мы перевернули вещи так, что событие UnhandledException срабатывает до того, как подключается отладчик, что, по-видимому, является тем, чего большинство людей ожидают.
Похоже, что .NET 2.0 делает это лучше (слава богу), но, честно говоря, у меня никогда не было времени, чтобы вернуться и проверить.
Это приложение Windows Forms. Исключения, которые пойманы Application.ThreadException, работают нормально, и я не получаю уродливое исключение .NET(OK для завершения, Cancel для отладки, кто придумал это?).
Я получал некоторые исключения, которые не были пойманы этим, и в итоге я попал в событие AppDomain.UnhandledException, которое вызывало проблемы. Я думаю, что я поймал большинство этих исключений, и теперь я показываю их в нашем хорошем окне ошибок.
Поэтому я просто должен надеяться, что нет никаких других обстоятельств, которые могли бы вызвать исключения, которые не будут улавливаться обработчиком Application.ThreadException.