What's the best way to minimize the need of run time checks?

[Steven D'Aprano]

On Wed, 10 Aug 2016 11:02 am, Chris Angelico wrote:

> On Wed, Aug 10, 2016 at 10:58 AM, Juan Pablo Romero Méndez
> <jpablo.romero at gmail.com> wrote:

>> This is interesting. You are Ok having runtime errors?
> 
> Absolutely. In real terms, there's no difference between "compile-time
> error" and "run-time error that you trigger the moment you run your
> program".

That's an oversimplification.

How about the difference between getting a compile-time error immediately
you try to compile your program, and a run-time error three quarters of the
way through processing a billion records, leaving your data in a corrupted
state?

You can say that this scenario is "rare", and you're probably right. But
that doesn't justify a statement like it is ABSOLUTELY okay to have runtime
errors (for programming bugs).

I love the fact that the computer on the Apollo lunar landers was expected
to have bugs, and was designed to automatically reboot and continue the
calculation that was interrupted. By memory, it rebooted something like 30
or 40 times during the first moon landing. That's awesome. But its also
unusual. Most software isn't designed to recover from errors quietly and
silently without any fuss.

But generally speaking, the only acceptable run-time errors are those that
occur due to information that are not available until run-time. If the user
insists on passing you an non-existent file name for reading, then what
else are you going to do other than fail with a run-time error?

Anything else is a *bug*, and while bugs are a fact of life, they
aren't "acceptable". As a matter of principle[1], we shouldn't release
software with bugs if they can be detected by either compile-time checks or
unit testing.

*Especially* if the consequences of a run-time bug are severe.





[1] As opposed to a matter of pragmatics.



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.