4 ms·
I'd be very interested to see non-BEAM approaches to enabling this - i kind of end up in the same pattern thanks to "expected? Return an Error<E>. Unexpected? T
by akdor1154 4y ago
I'd be very interested to see non-BEAM approaches to enabling this - i kind of end up in the same pattern thanks to "expected? Return an Error<E>. Unexpected? Throw." However, the supervising part is then difficult.
How do people approach this in Python? NodeJS? Rust? .NET?
- jetbalsa 4y agoIts common for me in PHP land to call die("Error! $e"); when something really bad has happened in a request and I really don't want anything to happen
- akdor1154 4y agoYeah nice, PHP's request scoping is a really good fit for this.
- theluketowers 4y agoThat's not without its drawbacks however, especially when you consider tools like swoole and laravel octane that keep your application in a long running process, so if you use die you actually kill one of the server workers instead of just terminating the execution of the request
- vvanders 4y agoYou can take the same patterns and apply them, it just takes a little more rigor since beam/otp had this built in. My favorite is hardware (or software) watchdog timers. Very simple to implement and surprisingly effective.
- game-of-throws 4y agoIf you can stomach kubernetes, you get this for free for all languages. Just panic!() or die(), and you'll get a fresh pod in a few seconds. Outside of k8s I try to use the lang's preferred tool. Python -> supervisord, Node -> pm2, etc.
- andrewingram 4y agoIf you’re doing web stuff, frameworks will basically have this built in. Typically the framework’s own request handler will have something that catches all uncaught exceptions within the scope of that request and return a 500 response. So within the context of a single request you can usually adopt a “let it crash philosophy”. In fact, it’s something most people seem to do intuitively.