2 ms·
The idea comes from an old paper “crash only software[1]” that’s pretty short (6 pages) so I would recommend reading it. Basically servers/services that don’t
by baby 5y ago
The idea comes from an old paper “crash only software[1]” that’s pretty short (6 pages) so I would recommend reading it.
Basically servers/services that don’t crash don’t exist. There’ll always be bugs. So instead of trying to fix all bugs, write code that can will gracefully fail and easily recover.
[1]: https://dslab.epfl.ch/pubs/crashonly.pdf https://dslab.epfl.ch/pubs/crashonly.pdf
- svrtknst 5y agoOne benefit of the "let it crash" mentality - provided the language and runtime has the right set of tools - is that you can focus on programming the happy path. Simplified example, but if part of your app is a parser, you can write functions that parse known tokens. If the input contains bad data, your parser will crash. Its supervisor will detect this and be able to restart the parser,and can pass an error back to the user. Now, should you add on code that handles known errors more gracefully and provides more info? Absolutely, but you don't have to, and imo that enables a very pleasant programming experience