QUIC: We should never catch an exception in event callbacks

[geoffkizer]

Currently, we have a try/catch around all our msquic callbacks. If we catch an exception, we log it and return MsQuicStatusCodes.InternalError.

We should also assert here and fix any cases in which the assert fires. There should never be a valid reason for an exception to occur here, and if it does, it's quite likely that we are in a bad state.

[ghost]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Currently, we have a try/catch around all our msquic callbacks. If we catch an exception, we log it and return MsQuicStatusCodes.InternalError.

We should also assert here and fix any cases in which the assert fires. There should never be a valid reason for an exception to occur here, and if it does, it's quite likely that we are in a bad state.

Author:	geoffkizer
Assignees:	-
Labels:	area-System.Net.Quic
Milestone:	6.0.0

[wfurt]

One case I look at recently is for example certificate validation. That can also run user code. The current code makes validation errors hard to diagnose.
I was thinking about capturing the exception here and throwing on next API call like SslStream does

ThrowIfDisposedOrExceptional();

That would allow us to propagate errors to the user.

[geoffkizer]

We shouldn't be running user code on the callback thread.

Edit to add: Though I'm not sure we have an alternative here; can you point me to where this happens?