Consider marking HandleProcessCorruptedStateExceptionsAttribute as obsolete/hidden

[Gnbrkm41]

System.Runtime.ExceptionServices.HandleProcessCorruptedStateExceptionsAttribute is an attribute used to enable handling of corrupted state exception (e.g. AccessViolationException) from the managed code, introduced in .NET Framework 4.0. This allows the consumers to deal with AccessViolationExceptions with the try-catch/try-finally clause and either swallow or log the exception instead of FailFasting. However, I personally have not seen legitimate use of the attribute but to work around crashes caused by flaky libraries or unsafe codes, and swallowing exceptions in such case can introduce a security risk.

Furthermore, there was a decision to disable the handling mechanisms of corrupted state exceptions in .NET Core.

Handling of corrupted state exceptions is set of low-level desktop features that tried to make it possible to write managed code for what would be best written in plain C. We have abandoned this direction and not included features from this set in .NET Core whenever we had opportunity to do so. Constrained Execution Regions (CERs) or stack overflow handling are other features in this set. None of them are in .NET Core, so we are differing in this area from desktop in general. Also, the different features in this set are tied together e.g. if you really want to write robust handler for corrupted exceptions, you would need CERs for that in desktop, so it does not make sense to pick and choose them in isolation.

Given that this attribute does not work anymore on .NET Core & it is inherently dangerous to use this attribute to handle such exceptions in the first place, I think the attribute should be obsoleted or hidden from the IDE to discourage the use of it. At the moment, it does not appear that this incompatibility is not so widely known (Searching on Bing/Google or looking at MS docs barely give any information about the state of the attribute on .NET Core). I believe that either of those options would effectively discourage the use of the type.

[danmoseley]

@terrajobst what is our current thinking about appropriate use of [Obsolete]? Perhaps we have this written down somewhere.

[jhudsoncedaron]

I used that once in Framework, at top level, to log the exception that was bringing down the application. While it would be nice that it worked in Core for the same reason, I would have ended up in the same place of redirecting standard output to the log anyway, because some of our devs keep writing recursive functions that don't reach a base case and it can't catch StackOverflowException. (Yes I would have loved to catch it even knowing I've got only 4K of stack with which to analyze and log the situation and the thread must die, but I digress.)