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

Chris Angelico rosuav at gmail.com
Tue Aug 9 22:02:37 EDT 2016


On Wed, Aug 10, 2016 at 11:47 AM, Steven D'Aprano
<steve+python at pearwood.info> wrote:
> 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).

Let me invert that statement, then, and assert:

It is NEVER acceptable to have runtime errors for programming bugs.

Okay. What does that imply? That *every single programming bug* can be
detected at compile time. Do you want to guarantee that? I certainly
don't, because it would shackle the program to "stuff we can
mathematically verify", which is a lot narrower than "stuff we can
currently code in Python".

So if you can't prove a program to be bug-free at compile time, what
*do* you want to happen with that undetected bug? I want a run-time
error, not a crash and certainly not the wrong behaviour.

Also, you'll notice that I said "the moment you run your program" -
that is, I'm talking about stuff that happens "at run time" but early
on, rather than waiting for data-specific situations. Ideally, you'll
have a test suite that exercises most, if not all, of your code paths,
and running your tests can be done at what's effectively the same as
"compile time" (with the significant difference that you can start
messing with the program without waiting for the tests to finish,
whereas it's annoyingly difficult to run a program that hasn't
finished compiling yet).

I never said that "run-time errors are preferable to compile-time
errors", because they're not; the sooner you catch something, the
better. But if you don't catch it early, yes, I am definitely okay
with a run-time error with a nice exception traceback and so on.

ChrisA



More information about the Python-list mailing list