How to handle exceptions in bindings?

[Ghostbird]

I have a collection view on dynamic data that is the result of an API call. This data is therefore deserialised to generic Newtonsoft.Json.Linq.JTokens. Now since this data is dynamic, I can have optional properties in there. I'm running into an issue where I'm trying to resolve a binding path: "[Foo].[Bar]" on a JToken where Foo is the JValue representing null. The binding will call get_Item on the JToken but calling get_Item on a JValue throws an InvalidOperationException. MAUI bindings properly handle internal errors such as KeyNotFoundException, but not the more broad InvalidOperationException.

Currently this means that loading that that has a value for Foo, but no nested Bar value instantly crashes my app, with no discernable way for me to catch that exception.

Is there some way I can solve this? I was thinking along these ways:

• Provide custom binding resolution code for Newtonsoft.Json.Linq.JTokens, so that it will not attempt to call get_Item on a JValue.
• Provide custom error handling on the binding so that I can prevent the app from crashing.

[Ghostbird]

I've noticed that this is caused because we use the square brackets binding notation. If I bind on Foo.Bar it doesn't crash. We use the square bracket notation because it is more flexible than the normal notation. E.g. if you bind to [Foo].[0].[Bar] where the value of Foo is an array, it works. I think we've hit a snag here, and must construct the binding expression more intelligently.

That can solve most of our use cases. We'll have to see what to do about optional arrays, but those are far more rare than optional properties.

[Ghostbird]

I've thought of this workaround. I'll bind to the root BindingContext of the data row, with a converter that gets our custom binding string as a converter parameter. Then I can resolve these dynamic bindings using custom logic. It's probably less performant, but since this is a bit more dynamic than the average use case for bindings, it's to be expected.