3 ms·

If your code is crashing more often than it is gracefully shutting down, you have a problem. Yes, you need to engineer for the crash scenario, but you shouldn'

If your code is crashing more often than it is gracefully shutting down, you have a problem. Yes, you need to engineer for the crash scenario, but you shouldn't be relying on that in the same way you shouldn't tell users the only way to stop your software is to `kill -9 [PID]`. In a normal deployment it might be useful to use shutdown parts of code to signal to orchestrators that the operation has been completed successfully so they can take further steps, for example. Everybody's circumstance is different, but I definitely recommend thinking more about shutdown workflows.

twic 6y ago
> If your code is crashing more often than it is gracefully shutting down, you have a problem. You have this exactly backwards. If your software crashes rarely, you have a problem - when it does crash. Because then it's doing something you aren't routinely and thoroughly testing by doing it all the time. This is an old, counter-intuitive, but powerful idea - if you're not familiar with it, start with this paper: https://dslab.epfl.ch/pubs/crashonly.pdf https://dslab.epfl.ch/pubs/crashonly.pdf