Типы исключений поврежденного состояния, отличные от AccessViolationException
Какие типы исключений Corrupted State Exception, кроме AccessViolationException, возможны?
В частности, можно ли предположить, что ни одно из OutOfMemoryException, ThreadAbortedException, SEHException, RuntimeWrappedException и т. д. не требует, чтобы использование HandleProcessCorruptedStateExceptionsAttribute было поймано, скажем, предложением catch (Exception)?
Меня даже интересуют примеры, догадки, приближения того, какие типы исключений иногда или всегда обрабатываются CLR как CSE. Существующие веб-ресурсы создают впечатление, что CSE является почти синонимом AccessViolationException, но я подозреваю, что это может быть слишком неточным даже для моих скромных потребностей.
Мне нужно знать, всякий раз, когда я замечаю catch (OutOfMemoryException) (или другую конструкцию, явно связанную с другими исключениями низкого уровня) в древнем коде, за который я периферийно отвечаю, мог ли код обработки исключений быть недостижимым или он рискует стать недоступным. , путем перехода на .NET 4.
До сих пор мне лучше всего было сканировать документацию Microsoft по типу исключения на наличие упоминания HandleProcessCorruptedStateExceptionsAttribute, но мне интересно, предполагается ли вообще, что эта деталь поведения полностью совместима со всеми версиями .NET 4 и/или тщательно задокументирована для каждой управляемой тип исключения, затронутый изменением CLR.
Ответы 1
Я не уверен, что существует даже конечный набор исключений (независимо от версий CLR, но в целом).
По крайней мере, собственный код (или сама CLR) может вызвать любое исключение, обозначая его как поврежденное состояние, если вы посмотрите на функцию это CLR.
// Signature simplified for purposes of that answer, check link above for actual signature.
void RealCOMPlusThrow(OBJECTREF throwable, CorruptionSeverity severity = NotCorrupting);
Эта функция (то есть макрос COMPlusThrow, который ее обертывает) вызывается в нескольких местах в (основной) среде CLR.
Функция IsProcessCorruptedStateException, по-видимому, в конечном итоге используется для определения того, считается ли исключение нарушением состояния. Эта функция имеет две «перегрузки».
Один довольно полезен, поскольку в нем перечислены следующие коды исключений:
STATUS_ACCESS_VIOLATION
STATUS_STACK_OVERFLOW
EXCEPTION_ILLEGAL_INSTRUCTION
EXCEPTION_IN_PAGE_ERROR
EXCEPTION_INVALID_DISPOSITION
EXCEPTION_NONCONTINUABLE_EXCEPTION
EXCEPTION_PRIV_INSTRUCTION
STATUS_UNWIND_CONSOLIDATE
По крайней мере частично они сопоставляются с объектами исключений .NET.
Однако другой «просто» чеки, если объект исключения (собственный, не управляемый) помечен как искажающий состояние.
Теперь я очень далек от того, чтобы быть экспертом в коде CLR, так что YMMV.
Конечно, можно провести часы в коде CLR, чтобы понять, как работает обработка поврежденного состояния и какие последствия это имеет для обработки кода C#. Но в зависимости от того, чего вы В самом деле пытаетесь достичь своим вопросом, который может привести к серьезному бритью. ;-)
Разделите пару Q+A созданный, как и было обещано.
Это было чрезвычайно полезно. Я узнал от вас, что «поврежденное состояние процесса» было существовавшей ранее концепцией, ортогональной типу исключения SEH (или управляемого). Я получил гораздо лучшее представление о типе условий, когда он попадает, и (из-за того, что заметил CorruptionSeverity.ReuseForReraise в коде CLR), что его перемещение внутри процесса через границы Reflection и AD также является необязательным, с TargetInvocationException еще одним примером потенциального CSE, и я опубликую особенно ценный урок об OutOfMemoryException в виде отдельной пары вопросов и ответов.