Я пытаюсь понять критерий .NET, когда исключения .NET подавляются, проглатываются или проходят незамеченными, чтобы обнаруживать/подозревать/предотвращать/быть начеку о таких инцидентах.
В онлайн-статье MSDN «Класс таймера» о .NET Framework 4.5 говорится:
В .NET Framework версии 2.0 и более ранних версиях компонент Timer перехватывает и подавляет все исключения, создаваемые обработчиками событий для события Elapsed. Это поведение может быть изменено в будущих выпусках .NET Framework.
Хммм, а .NET 4.5 — это уже будущая версия по отношению к .NET 2.0?
Хотя это риторический вопрос, и меня не очень волнует конкретный случай, упомянутый в документации.
Что меня действительно волнует и что я хочу понять, так это:
Каковы критерии, принципы и обоснование, в соответствии с которыми подавляются исключения .NET?
Обновление (в ответ на ответ Евгения Рика):
Итак, вопрос в том, какой поток должен быть подвержен исключению am, выброшенному на такт таймера?
Цитируя статью MSDN "Обработка исключений (библиотека параллельных задач)" :
Если вы не ждете задачу, которая распространяет исключение, или не обращаетесь к ее свойству Exception, исключение эскалируется в соответствии с политикой исключений .NET при сборке мусора.
(Забавная "политика исключений .NET", которую я нигде не мог найти...)
Что ж, меня интересует приложение WPF, которое, как я понимаю, является STA и имеет один основной родительский поток.
Я хочу, чтобы оно вылетало, если какое-либо исключение не было обработано.
Update2 (в ответ на комментарий Мэтта Смита):
Да, я знаю. Ссылаясь на <ThrowUnobservedTaskExceptions> Element:
Если исключение, связанное с Задачей, не наблюдалось, нет операции ожидания, родитель не присоединен и свойство TaskException не было прочитано, исключение задачи считается ненаблюдаемым.
В .NET Framework 4 по умолчанию, если задача, имеющая ненаблюдаемое исключение, подвергается сборке мусора, финализатор выдает исключение и завершает процесс. Окончание процесса определяется временем сборки мусора и финализации.
Чтобы упростить разработчикам написание асинхронного кода на основе задач, .NET Framework 4.5 изменяет это поведение по умолчанию для ненаблюдаемых исключений. Ненаблюдаемые исключения по-прежнему вызывают событие UnobservedTaskException, но по умолчанию процесс не завершается. Вместо этого исключение игнорируется после возникновения события, независимо от того, наблюдает ли обработчик событий исключение.
В .NET Framework 4.5 вы можете использовать этот элемент в файле конфигурации приложения, чтобы активировать поведение .NET Framework 4 по созданию исключения.
Я просто пропустил это, чтобы не раздувать вопрос и не получить ссылку на объяснение от Стивен Туб "Обработка исключений задач в .NET 4.5"
Вопрос в том, чтобы (очень хотел начать с этого вопроса) убедиться для меня:
- Существует ли общая «политика исключений .NET», упомянутая в MSDN "Обработка исключений (задача Параллельная библиотека)", чтобы четко сформулировать в одном месте?
- зависит ли он от версии .NET или независим?
- Где он сформулирован?
