So Unity comes packed with a great assertion API, and I plan on telling you all about why you should be using it.

For those that are unclear on what an assertion is, in programming assertions are used to say; at this point in my code I want this statement to be true and if it’s not, throw me an error.

For example say I have some function that takes in an int, a string and an array and I want some conditions to be satisfied. I might write:

This looks fun…

There are a few benefits to this;

If your program does break by hitting an assertion, you can very quickly see where the issue is and what exactly is the problem. Like in my example if I was to get errors or strange behavior due to that method being given incorrect input I would catch it straight away, even knowing which parameter was screwing me over. It can make your code more readable. Especially if you are working with others (or care about your future self) it makes very clear what conditions have to be satisfied at a certain point before the rest of a block of code can be executed.

Now obviously there is no need to go overboard with this, and assert the obvious or cases that clearly will never happen, but it still has it’s place.

Unity allows you to do this by using this class; https://docs.unity3d.com/ScriptReference/Assertions.Assert.html

It’s a pretty neat API, or at least that’s how TJ from Recess would describe it. You can use things like IsNotNull and AreEqual to check specific conditions you are interested in. Which also, in my humble opinion, help make your code and assertions even more readable.

Just to give you a quick example of what this would actually look like in Unity you would write:

The irony of promoting readability with single letter variables

In Unity there are some additional benefits to doing assertions, especially if you are developing for mobile platforms.

For anyone who has had the pleasure of using android monitor to debug a crash, you will know the pain of stack traces scrolling away from you and disappearing in a never ending torrent of useless logs.

Well assertions won’t fix that problem, but what they will do is stop you getting ambiguous null pointer exceptions to track down. Instead they give you a meaningful error and a useful log with exactly what condition is being broken and where that’s happening. The same is true for when using instruments for debugging iOS, though I do find instruments is normally a little clearer anyway.

So you may be wondering; hey, what about my live builds I don’t want code to break just because a pesky assertion is false. Well have no fear, assertions are only enabled in development builds (unless you specify otherwise) so no risk of that, and no performance hit for using them on live builds either.

And one final question you may have is; well why don’t I just use logs and exceptions? Well you still should, assertions are just another tool in the fight against bugs! They’re especially useful for asserting a condition about set variables, and can help you avoid having to account for branches in logic based on crappy input.

Overall using assertions has both improved the quality of my code and helped me catch some annoying bugs, and I hope I’ve been able to convince at least one person it’s something worth doing!