[mrkeen]

> You really don't want

And that's what this thread is filled with, and that's what I'm pushing back against.

> the RAI pattern is nice

> indicate if you are in different sections is nice

Style doesn't matter, flavour doesn't matter, wants don't matter, code "quality" (whatever that means) doesn't matter, niceness doesn't matter.

A transaction can be rolled back. If it can't, it's not a transaction.

[taeric]

I'd go a little further, though? Transactions have to be able to fail at the very last step. That could just be the "commit" stage. Everything up to that point could have been perfectly fine, but at commit it fails. More, the time of execution of that commit could be fairly far removed from the time of starting the transaction.

To that end, any style that tries to move those two time periods closer together in code is almost doomed to have some either hard to reason about code, or some tough edge cases that are hard to specify.

(Granted, I'll note that most transactions that people are dealing with on a regular basis probably do open and close rather close to each other.)

[mrkeen]

> I'd go a little further, though? Transactions have to be able to fail at the very last step. That could just be the "commit" stage.

I don't know what you mean by going a little further. I said transactions are 'all or nothing', not 'all or nothing or 99%'.

[taeric]

I meant only that there is no styling that can fix it. Some transactions will flat out fail partially done and have to be kicked to a reconciliation process to fix.

I grant that for things that are purely informational, this is not necessarily as accurate. But as the things reasoned about in a program get larger and larger, transactions span longer and longer timelines. With "all or nothing" not being nearly as clear cut as it is in smaller examples.

My go to examples are things like vending machines. (Granted, that almost certainly just shows my bias for state machines all the way down.)