BUT errors can happen

A process can always fail. The meaning of the process will include its expected outcome (e.g. "I open file -> file IS open") but we know, as a general principle, that processes can fail.

One of the failings of formal logic (as far as I'm concerned) is the need to account for this sort of global knowledge on a very repetitive local basis. Since we know attempts to do something may fail, it's difficult and bothersome to have to say so, every time.

But this begs the question: how do we define the semantics of error checking? Where do we put it? When the engine is actually writing a script, will patterns take care of error checking?

Since this is informal logic, actually all of the above can apply at the same time, so maybe I'm getting ahead of the game here. But it's an important notion.

Trust, but verify. Trust that a file can open, but verify that it actually did so. Trust that our script will work, but verify it using unit testing. The point is to describe the semantics of good programming, right?