What's wrong with this code?

[ShiftZ]

@eblade

SpawnActor most definitely can return null (what would it return if the spawn fails?)

I’ve given an example of a well known function that can fail but never returns a null pointer - opeator new.

@eblade

if you want the system to crash when a nullptr happens

If a function can return a nullptr under the given conditions it must be checked, otherwise the code is broken.
The problem here is that if someone claims that not checking the pointer for null is a mistake, he must have a substantial reason for such statement. But there is no such reasons exist.

@eblade

You should bring that to Epic’s attention, I guess.

I have decent experience communicating with Epic since a had an advanced support account and they were obligated to communicate with me and help me. I can tell you for sure that they don’t need my or anyone’s suggestions or advice.

@eblade

If you don’t want it to crash, then you check it. In fact, there’s a macro called check()

This is for debug purpose only and should never be used in a program’s logic. If a function can return a null pointer it shouldn’t be checked with ‘check’. ‘check’ basically sais “the expression must never be true, otherwise the program went into invalid state and must to be continued in debug mode and undefined behaviour in release”. If a function can return a null pointer, and it does, it is a valid state that must be correctly handled.

@eblade

Now, you should check for nullptr in PrintArray, because although there’s no usage of PrintArray outside of immediately after the spawn function, if it were used anywhere after that, it would be subject to failure, because you have no idea what has happened to any of the actors in that array in the subsequent time following their spawning.

Yes! You are absolutely right with the statement that I have no idea what has happened to any of the actors in that array in subsequent time. But tell me how did you come to the conclusion that I must check the pointers for null? Since when do raw c++ pointers become null if the object they points to is destroyed? In the real world pointers to destroyed objects become invalid and a simple check for null wont give you a false value. That’s why there is no reason to check it for null once they were put into the array.

@eblade

TArray should be UPROPERTY

Did you check how UPROPERTY defined?
Well, let me save your time:

#define UPROPERTY(…)

Do you know what it means? It means you can write UPROPERTY wherever you want, because it does absolutely nothing. You could use UFUNCTION, USTRUCT or UMETA on you choice. They all do the same - nothing. Is is a keywords for UBT preprocessor, it can be used only within class definition scope in header files and never outside. If you’ll write it outside of class definition scope, you’ll get an error from UBT. Non-header files are not even getting processed so you can write UPROPERTY whereever you want and how many you want.
Even if it was a header files, even if it was a class scope, in the given case it will still do absolutely nothing. And I dont see a point to explain why anyfuther. There is an answer in this thread if you are curious.