Hacker News Reader

Hacker News

Comment by pjc50 | Hacker News Reader

Parent Full thread

pjc50

> Let it go. Let it crash

It must be nice to work in an environment where nobody cares about results.

View on HN

> It must be nice to work in an environment where nobody cares about results.

Not crashing when there's a bug is not "success", it's just "zero visible errors"!

If your workplace really cares about results, they'll understand how futile it is to keep executing even though there's a bug. You start second-guessing your own program, which makes the code quality worse as the assumptions it makes are no longer clear; you won't be alerted to problems, as the program won't be aware of any; there'll be no guarantee that your code isn't just working "by accident" at the moment.

I'd love it if the code I deal with just crashed instead of pretending everything's alright, because it makes errors far harder to diagnose.

No one is talking about keeping execution instead of crashing. C++ smart pointers do not do that, optional types do not do that, no programming language whose creators are in their right mind has ever pursued that. You have just produced a classic example of a straw man argument.

>> Grandparent: "I think you should just let your code crash."

> Parent: "I think that is a bad idea."

It seems pretty clear that we're talking about crashing here.

There is a third option to crashing vs. not crashing: not letting the code compile if there is any chance it might crash. That is what this "buzz about null pointers" is about.

Oh, right. Yeah, that would be nice, but my company doesn't use languages with that feature, and we can't re-write our software, so we're stuck with Option types.

What magic compiler can certify my program will never abruptly stop, or worse do something unintended, because of hardware failure?

I detect a moving goalpost here, but if you're genuinely concerned that hardware might change the value of your bits then nothing else but lockstep execution will help. e.g. TI Hercules: http://www.ti.com/lsds/ti/microcontrollers-16-bit-32-bit/c20...

(Checking for NULL in your program won't save you from hardware failure either)

I hope I'm just being pedantic rather than moving goalposts, I'm all for better assurances. To me the only compiler "not letting the code compile if there is any chance it might crash" is either magical or never compiles a thing.

"not letting the code compile if there is any chance it might crash"; well, normally we assume correct operation for the hardware here in order to make that achievable, otherwise things could simply crash at any time. You're always vulnerable to single-event-upsets from cosmic rays or even alpha decay inside the chip packaging. Being pedantic about this in a discussion of compiler correctness is useless derailing.

"Rowhammer" over in https://news.ycombinator.com/item?id=15515044 is perhaps the most likely problem of hardware non-correctness to worry about.

When talking correctness (or security) I would think pedantry would be more welcome. I think you have a point on derailment if the comment I replied to had given a specific example that refused to compile anything with a chance of crashing, e.g. through guarantees of its type system, and then I come along asking about cosmic rays. But they didn't, they were vague, and I'm still left wondering of an example because even Haskell programs crash with a segfault or bus error sometimes. It's perfectly fine that it can't cover those cases but a compiler did sign off on a program with a chance of crashing, no cosmic rays involved, at best it only assures less likelihood of crashing compared to another compiler.

Reply on news.ycombinator.com