Thanks especially for clarifying (2), that sounds a lot more reasonable to me now.

Thanks for your insight! You are absolutely right! I agree with you in every respect … if I’d be working in a C or C++ environment like you do. I do know those rules you pointed out. Still, I decided to violate them and there are good reasons to do so:

(1) Any return-logic inside an assert will never be removed.
We do not work with a pre-processor. The asserts stay in the production code. Yet, we definately try to make sure, that asserts do not have any other side effects, though!

(2) Early-outs prevent Flash from throwing any exceptions. While using exceptions is quite handy in a debug-player, they will silently crash any non-debug players without any message whatsoever. Doing it the way I decribed, we get a decent error message even when the game crashes in a web browser.

(3) There is no way (that I know of) to savely show an assert message and then stop the processing of a Flash application as you can e.g. on PC or consoles. We solved this by simply leave the function early and then show a huge pop-up containing the assertion-message (in the next frame, which is simply the way flash works). The pop-up makes it impossible to continue to work with the game (although it still runs in the background). It doesn’t matter if the game state is corrupted afterwards, you won’t be able to see it.

(4) And it is a more convenient way to do the code-snipped you mentioned.

Thinking about it makes me wonder if I should have given the whole thing a different name. This would prevent people from thinking I am an idiot for breaking the most vital rules associated with asserts.

Cheers,
Manuel

Ouch! It really hurts me to see that. So you don’t want your function to crash? That’s ok if it’s a utilitarian function, like “GetDebugName” whose output is completely optional. Maybe even for something like a “Goto” command. So what if the NPC doesn’t move, as long as the game doesn’t crash. Or loading an asset, as in this case, then just use the default asset (checkerboard texture or default cube model or whatever).

Good. But as a general thing to build your asserts with return values, i don’t know. First of all, there’s a very common advice called “don’t put logic inside your asserts”. I would turn this around and say “don’t build your logic around asserts”. Most often, if the assert fails, the game already is in an undefined state and shouldn’t continue.

But then again, and maybe that’s the whole issue here, you are trying to build unit tests around your game code, and without some “softness” of error reporting (including delayed or disabled display of assert messages) it’s really hard to get right. Maybe that should have been stressed more.

As a general rule of thumb i would say that unless you are 100% sure that exiting a function prematurely doesn’t corrupt the game state, don’t use assertion return values in your code flow.

Your example is just a more convenient way to do the following:

CClass* pPointer = GetPointer();
Assert(pPointer);
if (pPointer != NULL) { … pPointer used here … };

I would prefer the explicitness in such cases.