ARM Blocks: ease of use and for loops

[Reinier Zwitserloot]

Oh, I thought you meant the reverse, that all Iterables had to be
CloseableIterators henceforth, errors occuring if they aren't.

The act of raising warnings or errors in the face of trying to iterate
across a closeable iterator without also calling the close method safely is
probably something for findbugs to find. I can come up with a few situations
where you want to do that. For example, because you aren't done with the
resource yet, because, say, it's a db thing of some sort and you want to add
a new row or some such.

--Reinier Zwitserloot



On Thu, Nov 12, 2009 at 9:27 PM, Howard Lovatt <howard.lovatt at gmail.com>wrote:

> I think the for loop failing on CloseableIterable is backward compatible
> because CloseableIterable currently doesn't exist. The reason I said
> controversially was that it would involve more work.
>
>   -- Howard Lovatt +61 419 971 263
>
> On 12/11/2009, at 1:25 PM, Reinier Zwitserloot <reinier at zwitserloot.com>
> wrote:
>
> "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>
> 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>
>> 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>
>>> neal at gafter.com> wrote:
>>>
>>>> On Wed, Nov 11, 2009 at 1:21 PM, Reinier Zwitserloot <<reinier at zwitserloot.com>
>>>> 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>
>>> http://www.messagelabs.com/email
>>> ______________________________________________________________________
>>>
>>
>>
>>
>> --
>>  -- Howard.
>>
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>
>