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