ARM Blocks: ease of use and for loops

[Howard Lovatt]

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