ARM Blocks: ease of use and for loops

[Reinier Zwitserloot]

"Controversial" as in: Not even close to backwards compatible? I don't think
that's feasible. A separate syntax to indicate that you'd like to
iterate-then-close, which warns or errs if you supply a non-closable
iterator, seems like a better idea. Lest we overload the try keyword too
much, and make code that isn't particularly readable ('try' does not scream:
Iterating through something iteratable to me), possibly look into:

try for(T a : b) {
}

We might as well start using the fact that try requires a block body.

for try(T a : b) {
}

and:

for(try T a : b) {
}

or even:

for(T a: try b) {
}

are all also unambiguous given the current JLS and should be easy to
retrofit into the existing grammars of javac and ecj.

--Reinier Zwitserloot



On Thu, Nov 12, 2009 at 10:55 AM, Howard Lovatt <howard.lovatt at iee.org>wrote:

> Reinier has raised a good point that you start with a CloseableIterable and
> end up with just an Iterable, this loosing of the Cloaseable type hasn't
> happened in my code (because I am looking for the problem). I can see that
> it would happen in other peoples code and also by mistake. I think this
> problem is solved by using:
>
> try(final String line : iterableFile) {
>    ...
> }
>
> The above try-for-each block will fail at compile time if iterableFile
> isn't of type CloseableIterable.
>
> Secondly, and more controversially, the for-each loop could fail at compile
> time if given a CloseableIteratable as opposed to a normal Iterable.
>
> 2009/11/11 Reinier Zwitserloot <reinier at zwitserloot.com>
>
>> The problem is: If you forget to retrofit a filter, or you're just using
>> one written with java6 or below in mind, then there's no obvious sign that
>> your resource is not being closed. No compiler error or warning. Not even a
>> pattern in the code you can detect. You'll notice a month later, when you've
>> released your product to your customers, who are starting to call in with
>> strange errors involving full DB pools and such. The fix is to write up a
>> custom findbugs plugin, or something similar. Given the way findbugs is not
>> even close to universally used, let alone used with custom plugins, that is
>> not at all a satisfactory answer.
>>
>> That's a very serious problem.
>>
>> --Reinier Zwitserloot
>>
>>
>>
>>
>> On Wed, Nov 11, 2009 at 10:30 PM, Neal Gafter <neal at gafter.com> wrote:
>>
>>> On Wed, Nov 11, 2009 at 1:21 PM, Reinier Zwitserloot <
>>> reinier at zwitserloot.com> wrote:
>>>
>>>> Unless all existing filters are rewritten to support Closeable, and
>>>> their close methods do an instanceof check on the contained Iterator and
>>>> pass on the close call if they are also ClosableIterators, I don't see how
>>>> that's going to work.
>>>
>>>
>>> That sounds like a workable approach.
>>>
>>>
>>
>> ______________________________________________________________________
>> This email has been scanned by the MessageLabs Email Security System.
>> For more information please visit http://www.messagelabs.com/email
>> ______________________________________________________________________
>>
>
>
>
> --
>  -- Howard.
>