3 ms·
> Exceptions come naturally from the realization that you mostly have to propagate errors to where they can be suitably handled or logged. I agree of course th
by jstimpfle 5y ago
> Exceptions come naturally from the realization that you mostly have to propagate errors to where they can be suitably handled or logged.
I agree of course that errors must be handled and logged as appropriate, but the implication that this has to happen by popping from the call stack is not justified at all.
- wvenable 5y agoLogging can be done but I can't see how you could handle errors. If I'm processing 10 transactions and transaction 8 fails, needs to be retried a couple of times before being skipped for 9, I don't know how you'd do that other than going up the stack to where you're looping over the transaction list.
- jstimpfle 5y agoNot everything is a transaction; and not all transactions are processed serially in non-overlappend time slices. Most systems will process multiple pieces of work concurrently (and can't just throw a new OS thread at each of them). The implication is that you can't just back out of a call stack like in a quickly hacked-up script. Stack frames aren't containers for whole transactions. Rather, pieces of work are tracked in explicitly allocated data structures, and worked on during more than 1 function call. The exception model is not compatible with this.
- wvenable 5y agoLanguages with async/await and exceptions have already solved this.