We use data bindings extensively (love 'em).
However we do find they contribute to bugs, and sometimes these bugs can be hard to catch. We got caught out today when the following (bound to a label text
property) failed:
f"$ {self.item_row['cost']:.2f}"}
In this case self.item_row['cost']
was unexpectedly None
. So the binding failed and everything died terribly (well, the form never loaded). We dealt with the conditional and all is well again.
Okay, yes, we should have anticipated it could be None, or should have prevented that from ever happening. Still though, the fact that this causes an error that basically kills the page feels disproportionate. Is it possible we could treat this as we would when an event_handler is specified but doesn’t exist, i.e. as a warning? At least for apps in production and without write-back… Returning ‘None’ (or the default value?) feels appropriate in most cases… If write-back IS on, then returning None would cause an exception only when the value is changed (when the value tries to be set) vs preventing the page from loading…
I tried to handle this with set_default_error_handling
but there was no way I could find to identify binding (vs other) exceptions.
Current behavior: On an exception in a data binding, an exception is raised.
Suggested behavior: On an exception in a data binding, a warning is raised and the default value is returned.