Something along that line, yes :-)
(Just wondering, since you seemed to say in the beginning that you did
not want to create objects (if I read this correctly), why creating
AutoCloseable instances here would not pose a problem ?)
Cheers,
mg
On 23/11/2020 00:45, Milles, Eric (TR Technology) wrote:
Now imagine that try-catch-finally wrapper method was an inlined closure, and
it inlines the closure it receives, then you get a solution to your problem
with very little overhead.
This may be in alignment with what you are saying. If I had a method
"auto(oldValue, newValue)" that creats an inline AutoCloseable AIC instance, I
could package up capture, mutate and restore within the enclosing scope.
try (auto(field, value)) {
...
}
would translate to this:
try (new AutoCloseable() {
def tmp = field;
{
field = value
}
@Override
void close() {
field = tmp
}
}) {
...
}
"field" could be any VariableExpression, PropertyExpression, AttributeExpression or
FieldExpression -- anything that is read/write. "value" could be just about any
Expression.
This way, the try statement could be its normal self. There could be anything
in the try block, there could be catch blocks and there could be a finally
block as well. And you could reuse this anywhere an AutoCloseable is accepted,
so withCloseable is an option in place of try.
