Function level try recourse directives.

[Brian Goetz]

> On Dec 28, 2022, at 12:06 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
>> I think there where many valid points against it mentioned. But I disagree with your scope thesis. The "open try resource" is not meant to be used like this:
>> void foo() {
>> 	..
>> 	{
>> 		try (..);
>> 		..
>> 	} 
>> 	.. 
>> }
> 
> Which is what I understand you mean by opening a scope just for the scope itself. It is meant primarily for use cases where your resource live the lifetime of the function, which is pretty common in well refractored code.

There was some sort of editing error here, the above sentence was part of Red’s mail, not my reply.  My reply begins here: 

> What you are advocating for is something like Golang’s `defer` statement, which queues up cleanup operations to run at function exit.  
> 
> But, the `defer` mechanism is a weak bit of language design; it forces developers to align method boundaries with resource management boundaries, even when the two don’t agree.  Yes, the two coincide often enough to make it seem harmless and even clever, but such couplings often end up being impediments to refactoring and the source of subtle bugs.  (For example, an “extract method” refactor may change the order in which resources are released.). Ultimately, it has many of the same deficiencies as global static state or nonlocal control flow — it interferes with modular reasoning.  Adding more of this into the language isn’t necessarily helpful.  
> 
> 
>> Which is exactly what the current existing try resource is. The motivation of feature is to remove redundant nesting.
> 
> I think this is the root of the problem.  This is not a very strong motivation for introducing a new and different form of scoping into the language.  
> 
>