Welcome back! Today, let’s talk about the probably most sensitive part of programming: error handling. This is a really big topic, so I made two articles out of it. This time I am going to tell you about our philosophy on that. Next time, I’ll show you how we turned our vision into reality.
Back to business: A project without proper error handling is doomed to fail after it has passed a certain level of complexity. Actionscript3 offers exceptions as a standard answer on the topic of how to deal with errors. Exceptions are for exceptional problems, but not for your little everyday error check. So, for us at Rough Sea Games exceptions are simply not enough. We like to be able to do what “The Pragmatic Programmer” [1] calls “assertive programming.” We add a lot of checks to our code to make sure we are still safe. If something goes haywire, our asserts make sure we crash early. That really helps to find the bug(ger) quickly. In addition, we like to ensure that “contracts” between methods are kept. That means, for instance, that if a method requires one of the parameters passed to it not to be null, we want to assert this to make sure it won’t happen. And if it does, we want an immediate feedback and not a some ambiguous crash further down the road.
Despite being a great help for the programmer, assertions can be a problem when it comes to performance.
Performance Issues
I did some performance tests while ago: I took out the assert method just leaving an empty stub. Oddly, this did not have a significant impact on the performance. So, the method itself is not very greedy. That’s good, but still, when I took out a couple of asserts the performance went up. How can that be? I found out that calling the method was the problem. Our assert method takes a string as one of its parameters. In some places we employed some heavy string operations to include values in that message.
When you do something like that inside an important loop you may be surprised about the great loss of performance. By refactoring some of those critical asserts, I could speed things up quite a bit without having to take the asserts out. So, if you are careful, asserts do not have to be a performance killer.
Better Production Code
Of course, taking the asserts out will produce slightly faster code, but since there is no simple way to actually take them out in a reversible manner (like using a preprocessor), we may as well leave them in for good. Some people may perceive them as a debug-only facility, but having them in production code might not be such a bad idea. We want to debug and improve our product constantly after release. A consumer that is able to tell us which assert exactly failed, helps us to find bugs a lot easier.
Well, I could go on about assertions forever … but time is scarce, so I’ll close for now. Next time, we’ll get our hands dirty and dive into our assertion code.
So, stay tuned and happy coding, Manuel
[1] The Pragmatic Programmer; Andrew Hunt, David Thomas, Addison-Wesley
ISBN 02161622X (http://www.pragmaticprogrammer.com)
Popularity: 9% [?]
Loading tweets...