Comments on: To assert or not to assert

By: admin

admin — Sat, 15 May 2010 19:58:07 +0000

Pavel: Not really. It’s not even about the performance, they’re simply not always fully supported on some platforms.

By: Pavel Shevaev

Pavel Shevaev — Sat, 15 May 2010 07:35:12 +0000

… and it looks like using exceptions for errors which should not be asserted is not an option in gamedev, right ? ;)

By: Mateusz Loskot

Mateusz Loskot — Wed, 03 Feb 2010 12:08:45 +0000

@Liam Regarding assertions in TDD. This comment lacks of details about context to judge use of assertions this way as a good or bad practice. I’m not saying I don’t agree with Fowler. Though, it’s nothing wrong to decide to use assertions as checkpoints in test cases. I don’t discuss if it is convenient or not, but from testing point of view, they fit it well – assertion checks if assumed condition is fulfilled or not.

By: admin

admin — Sun, 10 Jan 2010 12:46:58 +0000

OK, I see. I think we’re talking about same stuff, roughly. I mentioned separating error handling from asserts. Asserts are like last resort option that triggers if higher-level code didn’t deal with invalid input (like invalid index for example). With automated test system & automated error reporting (so that artists don’t have to run to you every time it crashes) it’s less painful than it may sound.
One problem I see with being too tolerant for data errors is that you end up with code filled with if (this) or if (that) that’s only needed during development (and probably shouldn’t be needed atl all with a little bit of effort and better tools).
Whole matter should also probably be treated in a little bit different way in tools & in game. Tools should be much more forgiving, I agree.

By: ed

ed — Sun, 10 Jan 2010 02:04:47 +0000

My guess is that you didn’t get my point :)
There are only two kinds of problems: those you foresee and those you don’t. Those you foresee are always “marked” with assert. If you place an assert in []operator then it means that you actually foresee a potential problem here: “index out bound = bad”.
Placing an exit() means “I don’t have time know, and I’ll deal with it when it happens”. And that is actually “sweeping under a rug” because this will never save your time. You will eventually spend that extra time to fix the problem. Question is why anyone besides you must waste his time ?

My point is: if program closes, I don’t care if that was SIGSEGV crash or an assert with message “Doh!”. This is always the worst thing may happen to user. You will loose lots of time (even 5min of work), you will waste your time on start/loading again and you will waste time waiting till problem gets fixed. That sumes up to a lot of wasted time.

You want feedback then track problems often. Database (as you mentioned), instant messaging, anything is ok. Placing exit() will not improve feedback. People (and I mean artists :) ) usually will get tool/game crashed 50 times before they’ll start whining about it. And running to a programmer, every time program crashes is another waste of time.

So, never let the tool/game crash. Check the list of the known issues often, and be user friendly.

About [] operator. In general solution, sure, you may return static variable (protect against read/write) but it would be much better if you place an assert before you use [] operator. There aren’t many places with [] usage. You can always place an assert at function entry. It will be easier for you to decide what to do if “index > size()” and skip plenty of code.

Yes, assert is “just” error handling (during a production time). But definitely it shouldn’t be yet another fancy way to crash a program.

By: Maciej Miasik

Maciej Miasik — Sat, 09 Jan 2010 18:17:22 +0000

Well, if there’s an alternative route/solution for the assert condition it only means that this isn’t something assert are for. This is just error handling.

Also, such approach diminishes feedback – instead of fixing the problem, it is only swept under a rug only to resurface later and/or elsewhere. It’s very difficult to judge any productivity gains from extended assert handling to those delayed loses which are result from using improper data or alternative solutions.

Anyone who loses 2-3 hours of work due to tool assert/crash should be educated how to use unstable, WIP tools first. Save often. Backup you work. Be prepared.

More frequently the problems that are indicated by asserts are fixed the better for end user.

By: admin

admin — Sat, 09 Jan 2010 16:52:34 +0000

I’m not convinced. I mean, if you foresee a problem, it’s not a place for assert. Asserts are for conditions that have to be satisfied in order for the program to work correctly. Once assertion fails, all bets are off. How would you suggest dealing with out of range indices in [] operator? Returning dummy values? What to do when we’re writing to array?
Asserts crashing tool/game can be a problem, but in my experience – not that critical. I worked in studios that used skippable asserts (or no asserts in release builds), worked in those that had asserts terminating the game (teams of 100+, not 1-2 programmers :), the latter seemed to work better (in my opinion). But yeah, that’s one of the things I’m not entirely sure about, just a hunch.

By: ed

ed — Sat, 09 Jan 2010 14:09:58 +0000

I disagree that assert should stop execution. If a programmer foresees a problem in a particular place he should deal with it instead of “i’ll-leave-it-for-later-maybe-it-will-not-happen-crossing-my-fingers”.
That’s why assert should behave like exceptions. You catch the problem, return from function or execute alternative path. I’ve seen that in one game (ASSERT_RETURN and ASSERT_ELSE).
Stoping the game/tool on assert doesn’t do anything good. It may be good for a 1-2 programmers and some pedantic manager. But it is never good for an user.
If you really, really, really want to stop the game on the ASSERT, do this ONLY during initialization. Stoping the game/tool in the middle of the session is a really bad thing and a complete waste of time for an user/tester/artist/designer etc. ESPECIALLY in the tool in which single assert may waste 2-3hrs of work.
Of course that is why also you need a lead/manager who will catch a problem ASAP and find anyone whos responsible for this.

By: admin

admin — Thu, 07 Jan 2010 20:46:28 +0000

Yes, I should have probably mentioned Charles’ article, it’s one of the best on this subject. I stolen shut-up-the-compiler-in-release-build-but-don’t-generate-any-code trick from it (sizeof(expr)).

By: Noel

Noel — Thu, 07 Jan 2010 17:54:32 +0000

It doesn’t do everything you want, but the assert implementation we used at Power of Two Games was the best I’ve seen so far. Charles wrote all the details (plus MIT-licensed code) here: http://cnicholson.net/2009/02/stupid-c-tricks-adventures-in-assert