3 ms·
Other responses are great. One thing I'd also point out is that the exceptions aren't really caught so much as the process is crashed, and the supervisor boots
by sb8244 9y ago
Other responses are great. One thing I'd also point out is that the exceptions aren't really caught so much as the process is crashed, and the supervisor boots up a new process depending on how you've set it up.
In practice, this means your processes need to be able to recover state when it boots up. I have some processes that act as caches of database values, which is the simplest type of recovery because you can just load from the db
- elcritch 9y agoAnother sub-point on your point is that restarting a process after failure can reduce the number of code paths that need to be handled after errors. Instead of having to handle multiple possible error paths and create multiple recovery methods to fix up state, it’s often simpler to crash and re-use the main initialization route to do the recovery. This way you end up with one well known and tested "initialization route". To build on your example, I’d imagine it’d be simple to have a check that compares the current revision of the cached data against a global version or timeout. Then if this check fails you just crash and allow the supervisor to restart the process. The regular initialization path will load the data from the database.