Function level try recourse directives.

[Reinier Zwitserloot]

 Lombok’s @Cleanup (https://projectlombok.org/features/Cleanup) works
exactly like that:

@Cleanup var foo1 = new Foo1();
@Cleanup var foo2 = new Foo2();


Does what you want. However, it runs to the end of the scope that foo1 is
defined in. An exotic java feature is that you can just write braces
whenever you feel like, so you can use that to scope your resources as
desired:

void example() {
  @Cleanup var db = ...; // scoped for the method, so closed at the end

  String acctName; { // note, just an opening brace here, on its own. Legal.
    @Cleanup var rs = db.query(...);
    acctName = rs.getString(1);
  }

  System.out.println(acctName);
}


It feels like the road not taken: That looks fine, is as flexible as you
need it to be (in that you control exactly where the resource should be
closed) and works great in daily use. It’s just… not what the
try-with-resources construct ended up doing. It feels a little odd to add
it *now*, and ‘just write some braces to scope some variables’ is not a
thing your average java programmer ever does. I’m not quite sure why not
(it’s quite useful given that java doesn’t make it easy to put helper
methods inside methods), but, it is what it is: Introducing this feature
more or less demands of the community that they get into the habit of
writing braces solely to define a scope. This is a big ordeal; for example,
most autoformatters will make this unduly ugly by forcibly trying to let
the opening brace start on its own line (sometimes, it’s own entire
paragraph, i.e. 2 newlines are injected), even though often it is more
convenient and easier to read to open it *after* the relevant variable
declaration, or a comment or label explaining what the point of this block
is.

A casual analysis indicates that going all out leads to nice results and
anything in between would incur significant costs. In other words, we
should have *either* a java where everybody is used to using braces to
create scoped blocks and the *only* variant of try-with is the stand-alone
one as you propose - *or* we have the java we have today, where almost
nobody knows it’s legal to just write braces to create a scoped block,
auto-formatters don’t know what to do with them, and try-with comes with
its own mandatory block.

Given that at this juncture it’s not possible to travel back in time and
get rid of the existing try-with (with the mandatory block), I’d say: This
idea doesn’t “work” for java. And that’s coming from someone who is so
convinced your way is better, he programmed it into lombok about a year
before try-with was introduced :)

In other words, better is great, but ‘does not demand significant cultural
adjustments and does not lead to endless style wars’ is better.

The costs incurred are high cultural friction, style wars, and likely, that
this alternate ‘form’ of try-with will be so rarely used, it will end up
being a member of that list of ’java lang features most programmers don’t
*ever* use and cannot recognize’. It’s not a good idea for that list to
grow any longer than it already is.

 --Reinier Zwitserloot


On 27 Dec 2022 at 14:49:13, Red IO <redio.development at gmail.com> wrote:

> I was once again writing closing heavy code in a java method and was
> wondering if I could reduce the clutter of the multi line try block:
> try (var foo1 = new Foo1() ;
> var foo2 = new Foo2() ;
> ....) {
> ...
> }
> Sometimes we need to initialize something between the resources and we get
> multiple levels of nesting.
> And I was wondering if we could not just lose the block and auto close at
> the end of a method like this :
>
> void foo() {
> try (var foo1 = new Foo1());
> //init some stuff
> try (var foo2 = new Foo2());
> // do some stuff
> // auto close at end of method
> }
>
> I think method level try recourse would improve readability and
> unnecessary nesting significantly.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20221227/c1157c64/attachment-0001.htm>