RFR: 8375016: Several catch blocks for NullPointerExceptions exist in the codebase [v5]

[Michael Strauß]

On Thu, 15 Jan 2026 22:27:03 GMT, Christopher Schnick <crschnick at openjdk.org> wrote:

>> my point this is not an equivalent change, because it changes the behavior.  Before the change, a null will be returned, after this change - a non-null value of some other class.
>> 
>> we don't want to change the scope of this PR, right?
>
> I added a test that should clarify the handling for mismatched types. The test passes both in the old and new implementation to show that the behaviour is the same and in both cases, null is never returned on mismatched types

This is not an equivalent change: Before the change, a `ClassCastException` could have been thrown from `observable.getValue()`, which is then swallowed and logged. After the change, the exception bubbles up to the caller.

However, the old code doesn't make any sense at all, because it doesn't do what the original author intended it to do. Christopher is correct: the generic type `T` doesn't have a lower bound, so it is erased to `Object` in the method descriptor: `()[Ljava/lang/Object;`. The statement `return (T)observable.getValue();` can therefore never throw a `ClassCastException` at runtime, because any reference type is convertible to `Object`. The try-catch block is dead code at best, and actually _hides_ an unrelated `ClassCastException` that was thrown from `observable.getValue()`; it confusingly logs that the "select-binding has wrong type", which is not what has happened.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/2032#discussion_r2785455568