[yoo1I]

No.

Yesterday my friends Mac crashed hard while they were working on a foolishly unsaved one-and-a-half page document in LibreOffice.

At the next start LibreOffice gives a big warning of "Oh shit things are really wrong, should I fix them for you? [Continue | Cancel]" .

Thank you LibreOffice team for making it so that within the time of a phone call to me plus the time it took to press "Continue" they were able to recover the their document and continue working.

This "attempt to rectify" the problem, could only have made things better not worse, so that's reasonable to implement.

I am not saying that every problem needs a solution like this. But blanket statements like "crash whenever there is a problem with your environment", while certainly the correct way to do it in some cases, leads to software that's really shitty use if that's all the software does.

Because while

> Almost all of these are the wrong numbers.

is correct from a programmers point of view, we aren't talking about the numbers a user put in, but rather numbers that the user has no control about.

And not many things are more annoying than computers doing unexpected things for reasons that are incomprehensible to you.

[elmigranto]

I don't think parent comment meant ditching swap files in text editors or reboot on GPS errors in plane's autopilot. Just sort out upfront where the value is (user data, safety and reliability, rendering fast, etc…) and set requirements appropriately.

There is no reason to handle leap seconds in a flappy bird game, or fork your database server to implement "proper" time handling with historically correct time zones and all the appropriate conversions between them, if you are writing a Twitter client.

[gpderetta]

>At the next start LibreOffice gives a big warning of "Oh shit things are really wrong, should I fix them for you? [Continue | Cancel]" .

> Thank you LibreOffice team for making it so that within the time of a phone call to me plus the time it took to press "Continue" they were able to recover the their document and continue working.

Uh, that's exactly what the OP was advocating, if I understand correctly. On a consistency check failure (i.e. an assert), crash immediately [1]. If the application correctly handle transactional state changes, it will be able to recover on startup from the replay log, as all changes are immediately persisted on the log.

This approach is known as "Crash Only Software", and it is pretty much the only approach for writing robust applications.

[1] Syncing the replay log to stable storage can be a good thing though.

[GauntletWizard]

Yes, and I'm consistently disappointed that HN no longer gets this - It's becoming an echo chamber of those who can't and won't, rather than those who architect and learn. Timekeeping considerations are rarely-to-never the responsibility of an application programmer, and the scenarios presented - Leap seconds, etc - Are either meaningless (Who cares if your delta-t value is off by a second over a three month report?) or incredibly meaningful to the point you explicitly define them in the spec (High-freqeuncy trading systems should use good linearization mechanisms, not just rely on 'timestamp' - The programmers who are working on these problems have well documented that these are hard problems that throwing more time specificity bits doesn't solve).

High level talks about low-level concerns are rarely helpful. This overview of detailed problems without links or even understanding of the relevant literature (It doesn't even mention the scenario that time runs backwards, which is way more common and terrible than pretty much anything on the list). This was a bad post, and it's bad training - Bringing up superficial questions without giving places to check answers for sanity. Many people will likely think about these issues halfheartedly, form half-baked answers, and propagate mistakes. Good learning not only asks questions, but asks follow ups and helps reach complete solutions.