Add SwitchExpressionException

[maryamariyan]

Fixes: #33284

cc: @danmosemsft, @ViktorHofer

[stephentoub]

What if the type of UnmatchedValue isn't serializable?

[danmoseley]

The purpose of exception serialization in .NET Core is basically telemetry (viz Azure Backup that requested we bring it back). So what I suggest is attempting to serialize, and if there's a SerializationException, create some kind of potentially useful string (using ToString and possibly ellipses?) and stuff that in there instead.

[danmoseley]

BTW if we think that's the right approach, then we should open an issue to make the same fix to ArgumentOutOfRangeException which serializes a private field of arbitrary type. In the .NET Core world, it's more likely that's not in fact binary serializable and since most exceptions aren't serialized most of the time, it wouldn't necessraily be noticed for a while.

Similar for RuntimeWrappedException and a few others. In fact serailization of XmlSchemaValidationException seems always broken - it serializes an object that looks like it can be (maybe always is) an XmlNode, which we don't support serializing. BinaryFormatterTestData tests a constructor overload that doesn't set this object.

@ViktorHofer

[stephentoub]

So what I suggest is attempting to serialize

We probably don't need to actually attempt to serialize, but could instead check obj.GetType().IsSerializable.

Regardless, your suggestion for what to do if it's false sounds reasonable: ToString() it and treat that as the UnmatchedValue.

[maryamariyan]

What is the pattern to use? i.e. where should I be checking for UnmatchedValue.GetType().IsSerializable?

[jkotas]

On the other end of the spectrum, the matched item can be a really big serializable object graph. You can end up with megabytes of serializable payload by accident.

If we think about the exception binary serialization should be optimized for telemetry, we may want to always convert the object to string to have a better chance for a reasonably sized payload.

The binary serialization of exception stack trace is handled in similar way. The stacktrace is converted to string for binary serialization because of the elements that it is constructed from are not binary-serialization friendly.

[danmoseley]

In the worst case ToString at least gives me the type name. Im thinking of how many times had to diagnose something with only the exception details in a log or bug report. That has made me quite biased towards including any potentially useful information. @stephentoub what are your thoughts? We seem to be having the same discussion in the linked issue 🙂

[danmoseley]

@arunjvs any thoughts, I believe you were or first customer for exception serialization..? See #35041

Always ToString might work although it could be worse if ToString is not usefully implemented on the type.

[jkotas]

I am all for having the right level of detail in ToString.

I just do not think we should spending any cycles on trying to make binary serialization better in creative ways. Binary serialization is a dead end.

[danmoseley]

@maryamariyan please go ahead and submit without the IsSerializable check, and we can have this discussion in #35041

[danmoseley]

LGTM with the contructors as specified by Immo.

[maryamariyan]

@dotnet-bot test OSX x64 Debug Build

@dotnet-bot test UWP CoreCLR x64 Debug Build

[maryamariyan]

@dotnet/dnceng UWP CoreCLR x64 Debug Build failure seems unrelated to change in PR:

Logs show

- FAILED 0x80080008 (Object server is stopping when OLE service contacts it
...
- 'XUnitRunnerUap' is not recognized as an internal or external command, 

For

System.Composition.Convention.Tests
System.Runtime.CompilerServices.Unsafe.Tests
System.Xml.Linq.Axes.Tests

[ViktorHofer]

That error is discussed here: #35142

[danmoseley]

CI was previously green, overall this was completely tested