Any failures will be caught. They're not logged, but they also weren't
before. Error handling can be improved at a future date, this series of
changes is primarily intending to unblock a new inspection.
A null there indicates a deserialisation error and therefore due to the
catch block immediately succeeding the changed line everything will
continue to work as intended.
They're mostly used in extensibility scenarios, so everything happens in
runtime. There is no better resolution than to crash with a null
reference exception.
There are seemingly no C#-side compile-time guarantees that it is safe,
but if the task's state is `Faulted` (as is checked right before), the
exception cannot be null as per the documentation.
If the null-checks were tripped, the test would crash anyway. It is not
possible to call `.Any()` and get a valid result instead of an exception
on a null reference.
`InternalChildren` can't viably be `null`, and if it were, we have
bigger problems. The removed null-check was triggering false-positive
inspections further down.
As it turns out, C# 8 provides an attribute that allows annotating that
an `out` parameter's nullability depends on the method's return value,
which is exactly what is desired here.