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.rom...@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. -- https://mail.python.org/mailman/listinfo/python-list