Failsafe application development: a visual as to how (errors)

I'm doing a series on failsafe application develoment this weekend it seems, driven by pure passion and inspiration. My first post described the what, my second explained the why, and this one's on the how

Having some insight into or experience with programming will help, but I hope you can also grasp the concept if you just think geeks are cute
As an example, I will take an easy creditcard transaction

First, I have to get two paradigms out of the way: the combine conditions as much as you can paradigm, and the combine functions as much as you can paradigm. They're both deadly wrong

Failsafe application development: a parable as to why

If you haven't got a clue about IT and applications, that will have changed after reading this. This post is about every day life, family, management, and control. It's a follow-up on my last post where I introduce failsafe application development - my way

In your life, you are the one that is aware of everything that's occurring around you. That doesn't mean you understand it, but it is enough that you can narrate it afterwards. With camera-equipped mobile phones everywhere, you can even objectively replay what happened - how's that for awesomeness
So, if anything out of the ordinary happens, you're there, you notice it
That doesn't mean you know why that happens because you don't always know the circumstances. If

Failsafe application development: everyone can do it

Error handling and solving has become a lost art. Over the last years the focus has shifted to delivering functionality rather than preventing errors. Hacks, hoaxes and viruses are some of the results, low-quality applications and user-unfriendly error messages are another

The reasons for this are simple. Increased business dynamics demanding quicker results, easier to understand programming languages lowering the threshold for programmers to code, ready-made reusable components available in increasing quantities and at decreasing cost are among the most important

It isn't that hard to write programs that never fail. Of course exceptions and errors will occur every now and then, but there's no reason to not catch them - which I describe as failing. I devised a simple, twofold mechanism that works in almost any programming language. I'm saying almost because I want to be careful, not because I've encountered a language in which it doesn't work