Greetings.
Interesting find when using a FINALLY block inside an iterating block.
If the iterating block is with a DB table buffer then accessing a single column in the FINALLY block will give a runtime error of 91 (no record is available), but no error if accessing the whole record.
FOR EACH dbTable:
FINALLY:
DISPLAY AVAIL(dbTable). /* always yes */
DISPLAY TableID. /* error */
/*
DISPLAY dbTable. /* no error */
*/
END.
END.
FOR EACH ttTable:
FINALLY:
DISPLAY TableID. /* no error */
END.
END.
It might have something to do with buffer scoping, if you keep the display available(table) then the error is gone... compile with xref and if there is a 'reference' to that table inside the finally block then accessing the field does not raise an error, if it's just the field access then the error shows.
Anyway, imho finally only purpose should be 'clean-up'... you'll get there even if there was an error or not, in the first case an undo was already performed... why are you trying to accomplish there?
Hi Marian, I think that is part of my point where if you don't have the AVAILABLE(...) statement then we get the error where clearly the code shows there shouldn't be an error in the iteration. So that doesn't seem right? But I do agree that FINALLY blocks do need to make sure that a record is available in case of entering in an error state but in this case there shouldn't be an error. I guess I should mark this one as a peculiarity.