3 ms·
The Erlang way doesn’t require exception handling code because processes are isolated, so when one dies the runtime can clean up after it (reclaiming memory, fi
by ramchip 3y ago
The Erlang way doesn’t require exception handling code because processes are isolated, so when one dies the runtime can clean up after it (reclaiming memory, file handles, etc.) as it knows what process owns what resources. Links and monitors make it possible to expand this to custom types of resources e.g. DB connections, locks, queues…
The idea is to implement error handling in the core (VM, supervisors, DB connection pool) while the vast majority of the code can just crash at anytime and not worry about closings its files or whatever.