Common Language Runtime Exceptions
In the "another VS"
<App completion item (don't have to commit it)
Technically nothing bad happens as a result of selecting the completion item (vs doesn't explode or anything); however, it still throws which is super disruptive.
This is, unfortunately, expected. I've run into the same problem, here's what's happening.
As you can see from your callstack SumConverter from VSLanguageServerClient is the last non-Newtonsoft parent of this. The way SumConverter decides which of its types is "correct" is that it just tries to Deserialize all of them, if one throws it tries the next one, if it succeeds then it decides that was the correct result. That means that for any given SumType Deserialization (of which CompletionItems are one) it is expected that exceptions are thrown.
So this doesn't represent a "bug" in that there is undesired behavior, but maybe we want to fix it anyway because this kind of control flow can make debugging a real pain.
Not quite sure who owns the type but are we able to change SumType on their side? If not, would creating our own SumType be a good idea in the future, meaning would there be any benefits?
I'm currently looking at changing the implementation of SumConverter to handle SumType conversions in an exception-less way using JSONSchemas. I feel like I'm making good progress on that, though it's certainly more fiddly than the current implementation, but if it proves more troublesome than I thought or if it doesn't work I'll probably seek advise from our resident JSON expert.
@ryanbrandenburg would this benefit from the blocked tag?
Yeah that's probably appropriate at this point. Basically my attempt to us JSONSchemas was pretty messy and fragile. The fix from their end would likely be when they move off of JSON serializing these things at all and into... @NTaylorMullen was it RPC?