Yep, the parameter name is structuretype in the ref assembly, but we cannot even consistently make up a wrong name that would stick and call it structureType or structure (and write tests for it).

Should this also include && IsWindows? I'm saying this because "Seh" is a Windows tech that should be limited to that platform. We should rename if this is describing a more general restriction.

The SEH specific APIs this is guarding work on CoreCLR, probably because of the built-in Win32 API emulator. The tests don't appear blocked for CoreCLR outside Windows. Is there a better name for "Marshal.GetExceptionCode and Marshal.GetExceptionPointers works"? (Or a broader question - do we need them to work outside Windows or should they just be PNSE?)

Yeah these APIs work on CoreCLR on non-Windows because the PAL layer emulates SEH and VEH-style structures for the exception handling infrastructure.

because the PAL layer emulates SEH and VEH-style structures for the exception handling infrastructure.

That is an implementation detail though. SEH is partially emulated in the sense we mimic it for managed exception handling but SEH as a concept isn't supported on non-Windows. Encoding it this way and saying it is emulated isn't really fair because we don't do propagation of exceptions in the way we do on Windows, which is what SEH really provides to us - a consistent exception contract we can rely upon for interop.

Or a broader question - do we need them to work outside Windows or should they just be PNSE?

@MichalStrehovsky I agree with this statement to be honest. The doc does state it is only supported for SEH, which to me means it isn't supported on non-Windows and can therefore throw a PNSE.

This is also a nit, so we can make progress on this otherwise. Please file an issue and @jkoritzinsky or I can work with JanV on the API changes and/or debate a better name.

The remarks section says "GetExceptionPointers is exposed for compiler support of structured exception handling (SEH) only.". I think that it is still an accurate general statement. People can use the API for other purposes if they know what they are doing, but we do not need to endorse or encourage in the docs.

Any suggestions for the naming of PlatformDetection.IsSehInteropSupported? PlatformDetection.IsHalfassedSehInteropSupported? I think that's the last piece of unaddressed feedback here. I'm not good with names and I'm obviously fine with naming it IsSehInteropSupported. I don't know what is the thing we actually support.

You can call it IsMarshalGetExceptionPointersSupported. It is exactly what this protects currently.

It also guards GetExceptionCode. Is the suggestion to have a separate PlatformDetection for each API?

I think so. I really dislike use of SEH because I immediately go to Windows only. Jan's suggestion works for me.