Just checked and it's actually going through the logger. I can change
that from "warning" level to "info", so it wouldn't normally show up.
-Martin
On 06/06/2013 07:43 PM, Richard Bair wrote:
I don't think we ought to print to stdout or stderr in any case in the
platform. A logger is a better idea. But really I think it is unlikely that
this particular message will be that useful (it will be unhelpful in just as
many cases). It is not uncommon for a chain to have a null in it at some point,
and the presence of the message will just make people think something is wrong
when in fact it isn't.
Richard
On Jun 6, 2013, at 9:31 AM, Kevin Rushforth <kevin.rushfo...@oracle.com> wrote:
Perhaps using the logging system would be a better choice in the case than
printing to stderr?
-- Kevin
Martin Sladecek wrote:
On 06/06/2013 10:53 AM, John Hendrikx wrote:
Hm, ok -- it is correct that it doesn't fail, the code runs without any problem
and everything works as expected.
But, what would be the way to avoid these messages in my log then? Something
like:
Bindings.select( Bindings.when(dataProperty().isNull()).then( ???
).otherwise(dataProperty()), "castings") );
??
I'd prefer to just turn these warnings off unless there is a really good reason
to have them (ie, they indicate a logic error or other bug, something I can
resolve...)
This might indicate a logic error in many cases, esp. when the property you
bind is a primitive type. When the select fails in the middle of computation,
the only it can do is to set the property to default value (which is 0). If the
developer
didn't expect this, it would be quite hard to find the actual cause of the
zero. If you really expect nulls along the way, it's much cleaner to handle
this explicitly as you do in the code above.
In my case the dataProperty() is often bound to the selection of a ListView --
if you have something valid selected, then a Detail Pane is filled in with
information about the selected item. When nothing is selected (ie, it is
null), then the Detail Pane should remain empty... I donot want to have to
remove/recreate these bindings every time some property becomes null.
Also, it seems rather wierd that JavaFX will complain about nulls in the first
part of the Bindings.select(), but will happily traverse the graph (with or
without nulls) for the other parts.
This is a bug then, it should print the warning in any part of the select
expression.
-Martin
