#begin

Assertive Programming

Let’s check out a section about assertive programming. We also talked about this earlier while discussing Design by Contract. Assertions allow you to use the compiler for certain conditions. Not just during testing, but also at runtime.

David and Thomas there is this mantra in computer science that says “ This can never happen… ” But we all know that what-ever this is, it can happen! If you want to make sure this never happens. Write some assertions for it to ensure it wont. Assertions can be added as pre and post conditions of your function. They can encode the conditions of your algorithms!

But a common mistake is to use assertions as a means of error handling. Assertions are for checking things that should never happen, not checking conditions that should ALWAYS happen. I think this is difficult to describe but the example they give in the book concerns a simple CLI where you ask for confirmation with either a ‘Y’ or an ‘N’. You could encode the check for checking the character in an assert statement but proper error handling is your friend here. They give the perfect example about you probably needing to handle side-effects like allocated memory or instantiated objects. If you simply assert you won’t be able to properly clean up what-ever you are doing.

If you do proper error handling with let’s say a try-catch then you can close files or streams in the catch clause. When you merely assert you cannot, and thus you leave it open and create memory leaks.

Since assertions are a compiler function they are often turned off by default. Assertions are usually only used for debugging. After a product is shipped you should no longer need them. David and Thomas think this assumption is false, because of two reasons. First not all tests find all bugs and second people forget that your system runs in a dangerous world haha. It’s true that assertions create some overhead and are supposed to be a debugging and testing facility. When you run your system in isolation it has a much more pristine environment. But when your system runs in the wild on other people’s computers there are a lot of things that can go wrong.

They also mention that if these assertions really slow down your system, you might turn certain assertions of in production but you can leave the ones that don’t impose a performance hit on. So I guess there is some nice middle-ground to find here.

Your first line of defense is good old error checking, secondly you can add assertions to check for the things that never aught to happen. And even then, turn of the ones that hurt the most performance-wise and leave the ones on at mission critical parts of the code.

So that’s it about assertive programming. How does this relate to Unity3D again? I’m not so sure. I haven’t seen much C# code in a Unity3D context that heavily uses assertions to check for erroneous conditions. I don’t think this practice is widely used in C# and Unity3D and I guess it never will be. It might be interesting to try. You can add the unity3d Scripting define called UNITY_ASSERTIONS to enable them and run your code. Have you ever done this!? If you do, let me know about your experience and if it improved the quality of your Unity3D application, in the comments.

#end

01010010 01110101 01100010 01100101 01101110