Article Number 000074263 - Forum - Knowledge Base - Progress Community

Article Number 000074263

 Forum

Article Number 000074263

  • An interesting point of view ... IMHO a dangerous assumption.

    Outlook for Android herunterladen

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • 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

    Outlook for Android herunterladen

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

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

  • Mike,
     
    No error handling is needed because there will never be a uniqueness constraint violation.
     
    Brian