An interesting point of view ... IMHO a dangerous assumption.
Outlook for Android herunterladen
Architect of the SmartComponent Library and WinKit
And as a matter of fact, the code in the quoted k-base article didn't follow your suggestion ... As there was no error handling at all. And that was what this thread is all about
Mike Fechner The problem is, that a developer reading only that internal procedure may assume that when the ASSIGN failes, the CREATE is undone. But it won't. Code should be easy to understand.
Are we projecting something here? I personally don't assume anything about follow-on developers so I try to communicate intent as often as possible. My personal opinion on TRANSACTION blocks is that it says "this all gets grouped together".
If a failure happens with CREATE - or any other place - the result will be a business logic issue that needs to be fixed regardless of whether the entire TX was backed out or only parts of it.
And I have seen cases in a TX block where the code ran into an runtime issue where part of the work was left undone w/out triggering the UNDO behavior, so a DO TRANSACTION isn't a 100% all-or-nothing guarantee.