Shouldn’t the returns of GetWorld() and GetFirstPlayerController() also be checked for nullptr? Is this an oversight (could be corrected in a future lecture for all I know) or is there actual reasoning behind going ahead with the full chain of GetWorld()->GetFirstPlayerController()->GetPawn()
This is an old question and I’m sure you’ve already figured it out but I’ll take a stab.
GetWorld should always be present so there should be no need to protect against a nullptr. No GetWorld = no game.
Similarly there should always be at least a First Player Controller - even if it’s just a passive camera (ie. machinma).
I suppose you could have a game of Life where you start it up and let the AI battle it out without ever knowing who won 
(I for one welcome our new AI masters)
1 Like
Well well now I can come in and ask something related, I feel like returning a nullptr is not the right thing to do, if we truly are object oriented programmers shouldn’t we return an empty object? just like the Null Programming Pattern describes.
Maybe Ben just wants to keep it “simple” but I would like to know what others think about this.
My thoughts are that nullptr makes sense, since it’s similar to the behaviour in lots of the gets for objects - and much easier to test for than checking if we’re dealing with an ‘empty’ tank in the return.
Well that’s the point of that pattern implementation, since you return an empty tank you don’t have to check for a nullptr, I’m still with you and I’d have done it with a nullptr but some people may agree that this is not good enough and I’d like to hear their thoughts.
Here is a good article about it http://www.yegor256.com/2014/09/16/getters-and-setters-are-evil.html