That 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.

That 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.

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

imo 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.

So, 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).

yeah i agree that seems like a generally desirable state of affairs.

not sure if i'd sign the statement "you typically communicate via a fairly narrow, well-defined channel, and not via a morass of side-effects" though ;)

Hey, it's aspirational ;-).

Haskell's STM monad.