3 ms·

Many, if not most of these things are problems with the environment, not things programmers should think about or try to solve. In fact, most of them should exp

Many, if not most of these things are problems with the environment, not things programmers should think about or try to solve. In fact, most of them should explicitly not be thought about. All that that will do is lead to defensive programming - What if X happens? What if Y? The answer to most of them is simple - Crash. Make it loud and clear that something is wrong. Any attempts to rectify the problem, and most attempts to even detect it will only add surface area to the code, surface area where you can screw up and introduce bugs. Could the system's timezone change? Yes. If you're manipulating time sanely, you're already using a timezone aware time class - particularly when serializing - and that's great. But if you're uncertain, it's best not to try to rectify. Your program will never be able to guess with any success. Almost all of this post strikes me as along the vein of the questions of Babbage - "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" Almost all of these are the wrong numbers. Rather than leading you to the simple, correct solution (Use good serialization formats and timezone aware datastructures) it leads you down a path of paranoia, convinced the world is out to get you. If you're programming for that world, you're either a DRM programmer and should burn in hell, or you're doing it wrong. Trust your environment and OS and make damn sure that when you're setting up those layers you set them up right - Don't worry that every second open() call will return an invalid filehandle, just because.

Rapzid 10y ago
Yes. To further play devil's advocate; a lot of times it's better to just write time handling in a naive manner. Even if you know it will fail under certain circumstances, the program might not need to always be correct to be successful. I HATE writing stuff like this, but sometimes the ROI is just not there.
kingcong5 10y ago
Yeah, same thing I was thinking. Being exact in time can drive you crazy. Don't run yourself in the ground.
kasparsklavins 10y ago
There are situations in which it is not acceptable to make a "loud crash", e.g., while a plane is flying. There was a quote by a nasa engineer that an incorrect action is better than no action at all, but I cant find it at the moment.
- gpderetta 10y ago
  I'm pretty sure that if a flight computer detects an inconsistency, it will immediately reboot, and not try to limp along in a bad state. Either the reboot is fast enough to recover quickly enough, or the redundant systems will take over.
yoo1I 10y ago
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 10y ago
  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 10y ago
  >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.
fauigerzigerk 10y ago
>Many, if not most of these things are problems with the environment, not things programmers should think about or try to solve. In fact, most of them should explicitly not be thought about. All that that will do is lead to defensive programming - What if X happens? What if Y? The answer to most of them is simple - Crash. When it comes to time, a crash is not the most likely outcome of not thinking about what could happen. More likely your code will stall or do the wrong thing. Think about polling, pinging other systems or rate limiting. At the end of daylight savings time your code could easily stall for an hour or DDOS another system because rate limiting fails.

Rapzid 10y ago

Yes. To further play devil's advocate; a lot of times it's better to just write time handling in a naive manner. Even if you know it will fail under certain circumstances, the program might not need to always be correct to be successful. I HATE writing stuff like this, but sometimes the ROI is just not there.

kingcong5 10y ago

Yeah, same thing I was thinking. Being exact in time can drive you crazy. Don't run yourself in the ground.

kasparsklavins 10y ago

There are situations in which it is not acceptable to make a "loud crash", e.g., while a plane is flying. There was a quote by a nasa engineer that an incorrect action is better than no action at all, but I cant find it at the moment.

gpderetta 10y ago
I'm pretty sure that if a flight computer detects an inconsistency, it will immediately reboot, and not try to limp along in a bad state. Either the reboot is fast enough to recover quickly enough, or the redundant systems will take over.

yoo1I 10y ago

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 10y ago
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 10y ago
>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.

fauigerzigerk 10y ago

>Many, if not most of these things are problems with the environment, not things programmers should think about or try to solve. In fact, most of them should explicitly not be thought about. All that that will do is lead to defensive programming - What if X happens? What if Y? The answer to most of them is simple - Crash. When it comes to time, a crash is not the most likely outcome of not thinking about what could happen. More likely your code will stall or do the wrong thing. Think about polling, pinging other systems or rate limiting. At the end of daylight savings time your code could easily stall for an hour or DDOS another system because rate limiting fails.