ARM Blocks: ease of use and for loops

[Howard Lovatt]

Yes, that is a good point. Probably better to leave for each alone.  
That leaves introducing CloseableIterable and some new syntax for try- 
for-each loop as the best bet. I would also favour SafeCloseable and  
SafeCloseableIterable in addition to Closeable and CloseableIterator,  
since I find the close exception pollutes everything.

   -- Howard Lovatt +61 419 971 263

On 12/11/2009, at 9:30 PM, Reinier Zwitserloot  
<reinier at zwitserloot.com> wrote:

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

>> This email has been scanned by the MessageLabs Email Security System.
>> For more information please visit http://www.messagelabs.com/email
>> ______________________________________________________________________
 

>