3 ms·

> Exceptions mainly allow you to be lazy This is not quite right. Exceptions allow you to be safe. Think of it like a factory that's practicing Toyota design

> Exceptions mainly allow you to be lazy This is not quite right. Exceptions allow you to be safe. Think of it like a factory that's practicing Toyota design -- any worker can pull a alarm that stops the entire production line if there's a critical safety issue. For code, this alarm pull is the exception. And when you pull it, everything restarts from scratch so it must be in a good state on recovery. Sometimes if a component fails, there is no clear and logical way to recover from the intermediate state (perhaps there are unsafe or insecure assumptions that would need to be made to keep going), so it's better to give up.

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 ago
  The 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.

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 ago
The 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.