I have to agree with Druha on this one. While the idea of ‘always checking for null’ may seem like good practice, I think it can actually lead to a way of thinking about error state handling that isn’t good and can result in more difficult to track down problems.
As Druha says, it really comes down to what you know and can expect about the input values to functions, or the return values of functions you are calling; along with how you intend to handle an undesired null pointer. If null is a valid value for a variable to have at a particular point in code, and you understand why it might be null, then you absolutely should check and handle accordingly.
The practice I disagree with is wrapping blocks of code inside a null pointer check just ‘to be on the safe side’, when you aren’t aware of if, when and why the pointer could be null. This isn’t so much handling an error case as pretending it’s not there - instead of causing an exception so you can debug and find out why it was null, you just omit doing what you wanted to do. In some cosmetic cases this might be fine, but generally, if you’re expecting your code to get executed, not executing it because of an undesired null pointer is likely to have adverse consequences further down the line.
I’d recommend using the check and ensure macros provided in UE4.
/* This is essentially the same as not doing a null check, but is a bit more explicitly self documenting. */
/* This is wrapping code in a null check, but explicitly showing that a null pointer is an unexpected state that needs investigating. The debugger will break here on a null pointer, but allow you to continue running. */
Bottom line: try to always understand when and why a given pointer might be null and deal properly with each case, rather than relying on a catch-all fallback. Admittedly, with the lack of C++ documentation of UE4 API functions, this can be difficult in practice.