3 ms·
I agree about the idea of pulling the alarm handle when some state goes wrong. However the problem is the notion that the problem is in the code (after all, exc
by jstimpfle 4y ago
I agree about the idea of pulling the alarm handle when some state goes wrong. However the problem is the notion that the problem is in the code (after all, exceptions cancel the scheduled code). No, the problem is in an individual object / data structure, and as I said simply cancelling all the stuff is fine for a script (or a web request handler if you want) but I don't think that's how you build complex, reliable and deterministically performing systems.
- throwawaymaths 4y agoThe claim is not that the problem is in the code. The problem is something like "database is unreachable" and yes, this is exactly how you build complex and extremely reliable systems -- it's the underpinning of how Erlang systems can have uptimes in the years. Fundamentally it's also how kuberbetes works. One of the containers has pulled it's alarm, so the pod "supervisor" restarts it.
- jstimpfle 4y ago> The claim is not that the problem is in the code. But exceptions act very much like the problem was the code. They cancel the following code in any function on the stack, which in general is unrelated to the error in the state where the exception originated. Another problem is that the exception originates from code instead of the object that is in a bad state. In other words, you need to step on a landmine to even notice that the object was already bad. It would make much much more sense if the "exception" was stored with the object/handle instead of propagated up an unrelated call stack, a single time. With Erlang exceptions, the model might fit better I don't know. I looked at it many years ago but never used it.