trying out the prototype

[Reinier Zwitserloot]

The way you describe it is exactly how Lombok's @Cleanup works. From my
(possibly biased?) experience, its a fantastic solution. The usual format
one ends up writing is either:

public void foo() throws RelevantException {
    Type x = open();
    x.doOperation();
}

or:

public void foo() {
    try {
        Type x = open();
        x.doOperation();
    } catch (RelevantException e) {
        handleOperationFailure();
    }
}

where closing earlier is important, just add a call to x.close();

 --Reinier Zwitserloot



On Tue, Aug 24, 2010 at 8:37 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:

> How about this:
>
> // any block
> {
>    int c;
>
>    try FileReader reader = new FileReader( source );
>    try FileWriter writer = new FileWriter( target );
>
>    while( (c = reader.read()) != -1 )
>        writer.write(c);
> }
>
> The [try ResourceSpecification] statement can appear anywhere in a
> block. When the enclosing block completes, close() methods are
> invoked.
>
> It's almost as if we have destructors
>
> public void copy(File source, File target) throws IOException
> {
>    int c;
>
>    try FileReader reader = new FileReader( source );
>    try FileWriter writer = new FileWriter( target );
>
>    while( (c = reader.read()) != -1 )
>        writer.write(c);
>
> } // reader and writer will be closed upon method completion
>
> Since we piggyback it on an existing block, we can avoid one
> indentation, and making code more readable. Compatibility isn't
> broken, the new behavior of the block only arise if the new type of
> statement appears inside.
>
> The "try" keyword probably sounds unnatural for this purpose. Maybe we
> can use some other keyword or symbol.
>
> IDE should warn when it appears that an auto-closeable resource is
> not, but should be, initialized this way.
>
> Note, the auto-close behavior stays the same even if the enclosing
> block is a try block
>
> try
> {
>    int c;
>
>    try FileReader reader = new FileReader( source );
>    try FileWriter writer = new FileWriter( target );
>
>    while( (c = reader.read()) != -1 )
>        writer.write(c);
> }
> catch(IOException e)
> {
>    // reader and writer already closed!
> }
>
> Zhong Yu
>
>
>
> On Tue, Aug 24, 2010 at 8:40 AM, Serge Boulay <serge.boulay at gmail.com>
> wrote:
> > The "using" block in c# only allows one resource unless the resources are
> of
> > the same type. To use multiple resources they are nested or stacked
> >
> > using (StreamWriter w1 = File.CreateText("W1"))
> > using (StreamWriter w2 = File.CreateText("W2"))
> > {
> >      // code here
> > }
> >
> > instead of
> >
> > using (StreamWriter w1 = File.CreateText("W1"))
> >  {
> >      using (StreamWriter w2 = File.CreateText("W2"))
> >      {
> >          // code here
> >      }
> >   }
> >
> > Depending on the number of resources, the "using" block nesting can
> quickly
> > get out of hand.
> >
> >
> >
> >
> >
> > On 8/24/10, Stephen Colebourne <scolebourne at joda.org> wrote:
> >>
> >> On 24 August 2010 12:14, David Holmes <David.Holmes at oracle.com> wrote:
> >> >> (I guess this forms a case against the try-with-multiple-resources
> >> >> statement in general. The list of semicolon-delimited declarations
> >> >> enclosed by parentheses looks weird, anyway ;-)
> >> >
> >> > I tend to agree the syntax is awkward and far less readable than
> simply
> >> > nesting the try-with statements.
> >>
> >> Overall, I think the semicolon, multi-resource, aspect is more complex
> >> than the benefits it gives. Clearer code results from nesting the
> >> statements.
> >>
> >> Stephen
> >>
> >>
> >
> >
>
>