Microsoft-ui-xaml: Unhelpful error message when invalid resource key

[michael-hawker]

Describe the bug
Was trying to launch my application and getting a Error HRESULT E_FAIL has been returned from a call to a COM component. message on start with no additional information or stacktrace as to what the problem was.

Turned out, I had a StaticResource key referencing something that didn't exist by mistake. It'd be great if VS could point this out ahead of time or the runtime error message be more useful here for debugging.

E.g.

<Style x:Key="TokenizingTextBoxItemTokenStyle" TargetType="controls:TokenizingTextBoxItem">
...
</Style>

<Style TargetType="controls:TokenizingTextBoxItem" BasedOn="{StaticResource TokenizingTextBoxItemStyle}"/>

See the mismatch above in the Key to StaticResource lookup.

Expected behavior
Error message calling out no resource found with given key would at least be a pointer.

Error Details

System.Runtime.InteropServices.COMException
  HResult=0x80004005
  Message=Error HRESULT E_FAIL has been returned from a call to a COM component.
  Source=<Cannot evaluate the exception source>
  StackTrace:
<Cannot evaluate the exception stack trace>

Version Info

| Windows 10 version | Saw the problem? |
| :--------------------------------- | :-------------------- |
| Insider Build (19615) | Yes |
| November 2019 Update (18363) | |
| May 2019 Update (18362) | |
| October 2018 Update (17763) | |
| April 2018 Update (17134) | |
| Fall Creators Update (16299) | |
| Creators Update (15063) | |

| Device form factor | Saw the problem? |
| :-------------------- | :------------------- |
| Desktop | Yes |
| Mobile | |
| Xbox | |
| Surface Hub | |
| IoT | |

Additional context
Thought I had maybe filed a similar bug before, but couldn't find it?

[michael-hawker]

I can also get other weird errors during layout measure cycles with missing/invalid resource lookups from the resource dictionary. It really slows things down when I have to go hunt through my XAML to realize I didn't copy over another resource from some other dictionary.

It'd be great to improve all these dictionary miss type errors with more helpful error messages which call out at least the name of the key that can't be found. Then it'd provide a developer at least something to search for as a hint.

[chrisglein]

Looks like this is getting the outer exception, not the stowed exception. I would hope that .NET surfaces that error (because it's the real business), but it looks like this isn't the case. That's going to be part of the tool chain, not XAML itself.
@fabiant3 What's expected here from VS as far as giving the additional exception info?

@michael-hawker For your other mention of errors during layout and such, it would be helpful whenever you can to provide a repro (link to a repo or code snippet) so we can replicate the same errors you're seeing and dig in to get them fixed. So if you have something there, send it our way.

[michael-hawker]

Thanks @chrisglein, yup, just hit another case where I just got a blank "Value does not fall within the expected range"/"The parameter is incorrect" when I had a style for a ListViewItem container that held a duplicate reference to a visual item that was being added to the visual tree a 2nd time, when the next item was realized in the ListView. I can send you the details from a thread, and a link to the commit in a private repo.

In general though, all the exceptions when something bad happens when an element is being realized in the visual tree (be it a duplicated reference, during layout, during containerization, with a style key fail, etc...) are super non-descriptive and unhelpful which makes understanding the root cause near impossible. What's even worse is that they're usually uncatchable exceptions, so even if I know there's a potential for failure (like in my XAML Studio), there's nothing my app can do to protect itself or abort the operation to recover.

Ideally these types of exceptions would bubble up the inner error (in the case of a key fail or a duplicate item in the visual tree) and at least provide the keys, element names, element types involved with the failure; Basically, if I'm given any unique text related to the context of my app/resources it at least gives me a starting point to poke around and comment out code to see where a failure might be occurring.

[fabiant3]

Is this managed or C++? There should be stowed exceptions with more info (you might need to turn on mixed debugging).
As for the original issue _I had a resource that it did not really exist_, we had planned to make changes to our compiler pipeline to detect these cases and give you a compile time error (similar for Binding and other related misfires).
Unfortunately this will only happen post WinUI 3.0, currently we're shooting for tooling parity.

[michael-hawker]

Thanks for the info @fabiant3. I'm usually working in managed. When I hit an issue like this, I'll switch to mixed debugging. That sometimes gives me more info, but usually not much more to anything meaningful to feel that I can act on it.

[michael-hawker]

XAML Parsing Errors are equally unhelpful in many cases as well providing no details of what was failed to be parsed at runtime.