For the sake of consistency and reusability, I think it would be better to define $app as this is the general convention.

The app is only called in these error states, defining $app in the method and not using it except for the error states is something we're trying to move away from. So, this would be the preferred behavior for one off use cases.

If you want to add a line instead of to call to the function, this is the same for me.

The most important is to have the value resolved and not cause a PHP Fatal error.

To mbaker, check the place where I fixed that.
This occur during the save function and when the check fails.
In this case, this terminate by a PHP Fatal error due to the call of of function on $app that is not initialized.

sovainfo, if you have a look on the j3.2.0 beta 1, you will see that somebody changed several JError::raiseNotice into the $app->enqueueMessage but forgotten to initialized the $app

If you want to add more setError message, this is OK for me.
I am just wondering if this will not be display twice the error message.
Once with the enqueue and another one by the setError that may be displayed by caller.

Remark: the original code was raiseNotice and not raiseError
So this is just a message (notice) and not an error.

I am not sure this should "stop" the processing due to the error.

That is why I suggest to make it consistent with the rest of the code! The severity of the message is the same for failing to load and failing to store (update rules) the root asset.

Whether to "stop" was already decided, see no reason to change that decision.

Sovainfo, I don't know who decide what.
My contribution here is to report that there is a PHP Fatal error because the $app is not initialized.

If you are informed of decisions to change the logic and that require to report an error instead of a notification, then perform the change as you think it should be.

From my point of view, the objective is to fix the PHP Fatal error and that whatever method is correct for me.
I have just suggested a fix that do exactly the same as before to avoid regression bugs.

Change the logic will require more test to verify that there is no side effect.

SOME_ERROR_CODE is wrong also .... just looking through the language files, maybe
JERROR_AN_ERROR_HAS_OCCURRED.
Neither one is going to 'stop' things since this is not JError but i think probably the red message is probably correct in terms of severity so 'error' makes sense. Let's fix the immediate issue and then we'll deal with adding logging and whether this error should produce a user facing message etc separately.

This has been fixed with #2394 and commit 41305fb

Closing based on @wilsonge comment above