* Add an overload to handle .NET completion calls without going through JS interop.
* Add endInvokeHook on the client-side.
* Replace OnDotNetInvocationException with EndInvokeDotNet.\n\nCommit migrated from 4312b9a050
* Handle non existing dotnet object references and returns the error through JSInterop instead of bubbling it up to the caller.
* Every other error in JSInterop is returned that way.
* It makes sure that the error gets to the client and is sanitized appropriately if necessary.\n\nCommit migrated from a30f2cbb27
The fix for this is to use more ExceptionDispatchInfo! Basically
everwhere that we handle an exception is now an EDI. It's easy to pass
these around and they do the right thing as far as perserving the stack
in.
I de-factored this code a little bit to make all of this work, but it's
now pretty unambiguously correct upon inspection.
I started out wanting to get rid of the continue-with because we've
found that pretty error prone overall. However making this method
async-void started to ask more questions than it answered. What happens
if serialization of the exception fails?
\n\nCommit migrated from 0a27fd3ad6
Javier Calvarro Nelson
Brennan
Pranav K
Ryan Nowak
Ryan Brandenburg