Just had to find my old musing about different try-finally patterns for yet another novice to read...
https://stackoverflow.com/a/46930029/976391There is a subtle problem now, as syntax-wise "try" is NOT bound to the object variable assignment.
For a novice reading code the "gut-feeling" of try-finally is as yet another form of "operator bracket" similar to begin-end, and it feels more natural to write "balanced" and "self-contained" try-create-finally than the proper pattern.
Also, formal syntax-wise, it is still perfectly okay to write (from get go or continuing developing someone else's code)
o := TObject.create;
// some code
// some more code
// yet more code
try
...
finally
o.Destroy;
Programming-wise the above code is broken, we split apart the actions that are intimately bound to one another.
Syntax-wise it is a perfectly okay thing, a recombination intended by the "loose coupling" between the language "building blocks".
It feels better if the language syntax could represent the real situaiton that "create" and "try" logically is ONE, atomic operation.
So, the proposal:
what if the try block could be written after assignments of managed/reference types in a manner how funcitonal languages are writing "guards", that is WITHOUT the semicolon ?
o := TObject.Create(...) try
....
finally
o.Destroy;
end;
This way the source text would be matching the intention that try-block is inseparable from the variable assignment.
More so, if in some later refactoring an exhausted or inexperienced programmer would try to insert (copy-paste, etc) any code between .create and try - that would immediately create a syntax error, hopefully waking the programmer up.