Useful design patterns to reduce risk of "bound value cannot be set" error
AndipaDec 14 2012 — edited Dec 18 2012The property binding approach of JavaFX is very powerful, but it brings forward a design problem in complex applications that I have no clear idea how to properly tackle.
If someone calls the setter while the property is bound, a RuntimeException saying "A bound value cannot be set" is thrown.
That makes sense, as it tells the caller that he (or someone else) is doing something stupid there potentially threatening other functionality.
However, a runtime exception is quite nasty and in distributed development teams and complex projects there is a risk someone adds a set or a bind call that would crash the application in a certain use case that was not properly covered by unit tests.
Are you using certain design patterns or coding guidelines to ensure this doesn't happen?
I could think of adding a call of unbind() to every setter method or requiring the call of unbind() before calling a setter in the coding guidelines.
Another approach might be to remove the setter altogether or discourage people from using it and bind to a constant anonymous property instead.
Any ideas? Maybe I'm also missing out on something vital, please enlighten me if that is the case.
Edited by: Andipa on 14.12.2012 06:07