4 ms·
Typically you then let the error bubble up in the supervisor tree if restarting multiple times doesn't fix it. Of course there are still errors that can't be r
by lawn 1y ago
Typically you then let the error bubble up in the supervisor tree if restarting multiple times doesn't fix it.
Of course there are still errors that can't be recovered from, in which case the whole program may finally crash.
- dns_snek 1y ago> in which case the whole program may finally crash. This may happen if you let it, but it's basically never the desired outcome. If you were handling a user request, it should stop by returning a HTTP 500 to the client, or if you were processing a background job of some sort, it should stop with a watchdog process marking the job as a failure, not with the entire system crashing.
- Muromec 1y agoreturning HTTP 500 as early as possible is an example of "let it crash" approach outside of Erlang.
- dns_snek 1y agoThat's not what "let it crash" is about. Letting something crash in Erlang means that a process (actor) is allowed to crash, but then it gets restarted to try again, which would resolve the situation in case of transient errors. The equivalent of "let it crash" outside of Erlang is a mountain of try-catch statements and hand-rolled retry wrappers with time delays, with none of the observability and tooling that you get in Erlang.