3 ms·
> For exceptions to work predictably, all mutation within a try-catch block should be captured in a transaction that can be rolled back. Wouldn't that just be
by heavenlyhash 9y ago
> For exceptions to work predictably, all mutation within a try-catch block should be captured in a transaction that can be rolled back.
Wouldn't that just be beautiful?
- ben0x539 9y agoimo the dream of exceptions is deferring error handling so happy-path code can be straightforward and free of worries, but if every line of code indirectly under a try-catch block has to embody transactional thinking to enable proper RAII behavior, that seems like a huge obligation.
- emn13 9y agoSo, that's the bad-stuff perspective. But transactions in actual DB's show it doesn't have to be that way, and transaction isolation is likely to be easier in a language than a DB because you typically communicate via a fairly narrow, well-defined channel, and not via a morass of side-effects. Another good-stuff perspective are processes or equivalents (e.g. erlang's internal processes or docker containers). Happy-path code can ignore errors; sufficiently serious errors tear down the "process" and the calling code can decide how to deal with that (ideally without cleanup responsibilities). As long as indirect effects are well-contained, there's nothing necessarily wrong with ignoring errors. Especially when fine-grained error handling simply isn't interesting, it can be a relief simply to ignore errors. E.g. DB style fine-grained locking is really only possible because you don't need to manually deal with each and every possible failure moment (because there are unbelievably many).
- the_grue 9y agoThat sounds like a natural fit for Rust's lifetime-tracking mechanism. The compiler can automatically drop all initialized objects upon exception. In fact, I'm reasonably sure it does just that for panic handling.
- panic 9y agoThat example is initialization code, but you'd run into the same problem even if the control were already initialized (and you were trying to set new properties on it). In that case, you'd likely have a borrowed pointer, so it wouldn't be dropped when the panic happened.
- ordu 9y agoThe pointer can be dropped. The pointed object cannot. So the problem of rolling back the transaction changes ownership, now our button should do sensible things in setLabel, to rollback changes made before an exception.
- anacrolix 9y agoHaskell's STM monad.