Catch Programming Errors as Early as Possible
Subj. That will save you a lot of trouble. Finding a mistake one level later costs ten times more.
For conventional programs, one can catch errors at these levels.
- Build environment assessing. Examples: host OS, host bitness, compiler version. Sense for environment and compare it with known/supported to you.
- Compile time. Check that types are at least that wide, structures are aligned. static_assert() things that cannot be false - you won’t lose in terms of speed of compilation with them, and will literally have zero effect on execution speed or code size.
- Run time. Put assert() over every expression that, in your opinion, would never be false. If it is always true, then it’s safe to put assert, right? A processor’s branch predictor will optimize if-then-else check inside assert, so the performance will be kept as well. Me, I always have situations when that “never-going-to-fire” assert fires on the first start of an application.
- Input data validation. User can and will give shit to your program instead of valid input. Security wise, input validation is a must. But it also helps to fail early on unexpected input, at least tying problem report to the input, not to some broken internal state in the middle of computation.
- Output data, or no output data but a crash mesage. If you got an error here, you are screwed. All traces of environment, input, whatever has happened along are gone. You’ll have to track the cause from consequences.
For software simulators, which run programs inside program, this principle is even more important. When debugging a simulator you really don’t know what is wrong - a simulator behavior, or a guest software code. Sometimes (and I mean often) they may both be wrong.
Take for example an interpreter loop of a simulator. One must check and report for errors as early as possible:
- On guest encoding processing. Real systems cannot have ambiguous encodings, so the input spec for simulator cannot either.
- During execution. If a target provided an undefined or otherwise strange from target specification standpoint instruction, it should be reported
- On checking results. If you are here, you are screwed. The good thing is that simulators sometimes can reverse time, so tracing from consequences to the cause might be somewhat linear complexity task.