Does my code correctly implement a correct system? A correct system, like a correct implementation, handles all possible edge cases via a predictable strategy[0].
In Puffins, any assumptions about the state of the system are expressed as assertions. Assertions crash upon failure, reporting the condition that failed, along with the their location in the source files.
Crashing may seem like something to avoid[1]. The reality is: if an assertion fails, the implementation and / or system is incorrect. Continuing would allow the system to explore un-predicted, potentially dangerous states. Even for my work in interactive installations, I prefer aggressive testing to catch and fix crashes. The alternative, despite my best efforts to write correct code, is clients reporting that things are behaving 'oddly', and little else to debug with.
For safety-critical software, NASA JPL, CERT C, and MISRA do not allow crashing assertions. Instead, they argue that such an error should be acknowledged and handled by the system, even when essentially fatal.
Puffins is not designed for such applications, so I avoid enforcing the complexity of having to check for errors after every function. Error checking semantics exist, but are reserved for the handling of un-trusted user input. Puffins assertions are for catching my mistakes, not the user's!
But none of the above strategies can guarantee predictable execution. Fundamentally, electrical circuits are always vulnerable to 'soft errors' such as bit flips. We must not assume that a computer system, even when implemented correctly, is 100% reliable. Safety-critical systems have learned this the hard way, and various methods have been devised to drive down the probability of failure[2].
The cultures that design systems, the implementations in code, the hardware that executes them - none are totally reliable! Engineering is always a compromise. Unfortunately, the sudden growth in leverage handed to software developers across the millennium, has largely stretched beyond our common sense, maturity, and technical competence. Check out some of the security entries on my links page if you would like to see what has informed my views.
[0] e.g: What does the system do when a cable tears, or if the user drags the application's window onto a different monitor? What does the implementation do when an integer overflows, or a pointer accesses a memory location that is no longer in meaningful use?
[1] I think this confusion arises because most modern devs work primarily on websites. The browser wants to prevent downloaded content from crashing it, no matter how ill-formed. An entire website's system and implementation is considered un-trusted input.
[2] All are fascinating: duplication of physical computers which compare results at critical steps, radiation shielding, error correction codes, to name a few... ↑ to top← to home