Configurable Behavior When Inner Observable Is Missing

[nipafx]

Description

All current nesting implementations specify their behavior when the nesting hierarchy's inner observable is missing. This behavior could be made configurable so that the user can pick another during construction of nested instances.

[acepe]

Currently if a NestedProperty's inner observable is missing, the NestedProperty keeps its old value and is not updated. This behaviour should be made configurable.

One option could be to clear the NestedProperty's value, by setting it to null.
Currently I am am doing that be adding a listener:

property.innerObservablePresentProperty().addListener((observable, wasPresent, isPresent) -> {
         if (!isPresent)
                property.setValue(null);
});

This listener has to be added to every NestedProperty, it would be much nicer if this could be included in the Nestings-API.

A different, however related, problem would be updates to the NestedProperty, if the inner observable is missing. Here I see three options:

1. no updates to the outer property (current behaviour)
2. try to update the outer property, which would result in a NullPointerException, because its value is missing
3. create (a value for) the outer property, then update it.

Option 1 needs no special handling of missing inner observables, which could be seen as a good thing. However possible errors in the programm-flow might not be discovered, because writing to a NestedProperty with a missing inner observable does not throw an exception, as it would with option 2.
Option 3 would be more work to implement, and I don't know if it really provides any benefits. I am not sure if object creation should be handled by a nesting...

[nipafx]

Thanks for your continued interest, @acepe! It's awesome to actually have a user and to know that my stuff is helping someone build their thing.

So we have two different questions:

• What happens to the nested property's value when the inner observable goes missing?
• What happens when the nested property is updated while the inner observable is missing?

NestedProperty's Value

It should be pretty easy to let the user chose what happens. I see the following options - these are methods on the different ...PropertyNestingBuilders, so the decision is made during construction:

1. whenInnerObservableMissingSetNull() (only where the created properties can contain null and do not wrap primitives - so not on, e.g., NestedIntegerProperty)
2. whenInnerObservableMissingSetValue(T value); this value will be set as soon as the inner observable goes missing (this must cause a change event)
3. whenInnerObservableMissingSetComputedValue(Supplier<T> valueSupplier); the computed value will be set as soon as the inner observable goes missing (this must cause a change event)
4. whenInnerObservableMissingThrow(Supplier<RuntimeException> exceptionSupplier); the supplied exception will be thrown as the inner observable goes missing

I guess this captures a useful set of possibilities. Btw, the method names are up for debate. 🚲⛺

Updates to Nested Property

Throwing an exception (on update) when the inner observable is missing sounds reasonable. (Maybe this should even be the default (in the spirit of fail fast). We're still before 1.0 so I'm considering to change this.)

On the builder:

1. whenInnerObservableMissingOnUpdateThrow(Supplier<RuntimeException> exceptionSupplier); the supplied exception will be thrown when the inner observable is missing and the property is updated

But how does this integrate with the options above? It feels overly complicated to allow both, e.g. when the inner observable goes missing, the nested properties takes on value x but when someone else changes it after that, it throws an exception. (By complicated I do not mean implementation but comprehension).

Opinions?

[acepe]

NestedProperty's Value

All four options seem reasonable to me. However personally i would probably only use option 1.

Option 1 could be named whenInnerObservableMissingClear() and extented to properties wrapping primitives, where it could set the default-value (e.g. '0' for IntegerProperty) instead of null.

If option 1 could handle properties wrapping primitive types, i see even less need for option 2 and 3.

Option 2 and 3 could have the same (overloaded) method name:

• whenInnerObservableMissingSet(T value)
• whenInnerObservableMissingSet(Supplier<T> valueSupplier);

Updates to Nested Property

I also think that throwing an exception on update when the inner observable is missing should be the default. I'm not sure if the builder option 'whenInnerObservableMissingOnUpdateThrow(Supplier exceptionSupplier)' is needed. Why not just throw a NullPointer Exception (after all the inner observable is null)? Or maybe a custom "MissingInnerObservableException" (could also be the default).

Method Names

I would change the method naming scheme to 'onMissingInnerObservable[...]'.
So it would be:

1. onMissingInnerObservableClear()
2. onMissingInnerObservableSet(T value)
3. onMissingInnerObservableSet(Supplier valueSupplier)
4. onMissingInnerObservableThrow(Supplier exceptionSupplier)
5. onMissingInnerObservableUpdatedThrow(Supplier exceptionSupplier)

[nipafx]

Nested Property's Value

I'm skeptical about ...Clear because it is implicit. Using 0 as a default value for primitives (and false for Boolean?) is less obvious (although still extremely usual) than an explicit ...SetNull or ...Set(0).

Overloading ...Set(T) and ...Set(Supplier<T>) would be my preferred solution as well. But overloading and lambda expressions do not always cooperate well (see this explanation by Stuart Marks). But I have to admit that it only fails in fairly artificial corner cases:

// neither of the following calls to 'onMissing...' compiles

ObjectPropertyNestingBuilder<anything> builder = // ...
builder.onMissingInnerObservableSet(null);

ObjectPropertyNestingBuilder<Supplier<String>> builder = // ...
builder.onMissingInnerObservableSet(() -> null);

ObjectPropertyNestingBuilder<Supplier> builder = // ... (note the raw type)
builder.onMissingInnerObservableSet(() -> () -> "anything");

Artificial as they may be, I'd like to avoid those cases.

Updates to Nested Property

You are right that a supplier for exceptions is overkill, so I will throw a specific one. I'm currently leaning towards IllegalStateException. NPE seems slightly off because the thing that is null (the value in one of the nested observables) is not the immediate problem.

But the most important topic is left untouched. How does throwing an exception on update interplay with those other options? I'll have to ponder that for a while...

Method Names

I like the on... prefix.

[acepe]

ok, if not ..Clear, how about ...setDefault, it would set the default value of the property, as it would be after initializing the property. Null for ObjectProperties, 0 for primitive number types, false for boolean.
I think if we have exception-on-update as the default behaviour, along with the current behaviour of keeping the last value, that plays along nicely.
If we provide the other options for setting a value, we should perhaps also provide an option to turn off the exception on update.

[nipafx]

Quick reply:

• ...SetDefault sounds good
• "keep last value" + "throw exception on update" sounds better and better; I guess this will become default
• I see basically two ways to deal with the other options:
  • silently turn off the "throwing exception on update behavior" (don't like it; too subtle)
  • allow to turn it off explicitly, e.g. onMissingInnerObservableDoNotThrow() (in this case the on... makes for a halting name)

I'm sure we will come to a proper solution for this, so I'll commit to implement this for 0.3.0.

[nipafx]

I thought about this for a while and had an interesting discussion about it with a colleague. We had the following thoughts:

1. If creating such a hierarchy, setting a nested property's value to null creates an illegal state and it would be best to immediately show this with an exception.
2. This would mean that some code deep in the bowels of the system might suddenly fail because the UI decided to pick this particular way to access the value. This would be awful and should not be default behavior.
3. Since the illegal state only becomes really problematic when a value is written, throwing an exception here is the absolute minimum which should be done to fail fast.
4. This behavior should be configurable.

This largely coincides with what we discussed here. I'd really like to implement 1. but 2. is a strong argument against it. It feels like we can't really win here...

About the method names. I'd like to use them to distinguish between what happens when the inner observable goes missing (e.g. setDefault or throwException) and what happens when a value is written while the inner observable is missing (e.g. throwException, storeValue maybe even writeValueToNextObservable).

[nipafx]

I'm almost done with this.

For future reference: throwing an exception when the inner observable goes missing is not very helpful because implementations of ExpressionHelper.fireValueChangedEvent catch exceptions, log and ignore them.