Community
Participate
Working Groups
try(stream = new FileOutputStream(someFile)) { // do things with stream } We should consider this for Closables and AutoCloseables (on the contrary to Java) and always compile to try { } finally { } with a reasonable idiom in the finally block.
Alternatively we could introduce a library function taking a Closable or Autoclosable and a block: tryWith(new FileOutputStream(someFile)) [ // do stuff with it ] Maybe with one (or two) overloaded variant for two (or three) closables.
Having overloaded variants may lead to unclosed resources if we implement this as a library function: tryWith(new FileOutputStream(fileA), new FileOutputStream(fileB)) [ .. ] Assuming the second output stream cannot be created and the constructor throws an IOException, the first one will never be closed. That's why I favored the compilation to a real try .. finally instead of the library approach. try(stream = new FileOutputStream(someFile)) { } could be compiled to FileOutputStream stream = null; try { stream = new FileOutputStream(); } finally { if (stream != null) { try { stream.close(); } catch(IOException e) { .. } } } This pattern could be applied to more than one closable in the try(..) part.
I see. What if we pass in providers: tryWith( streamOne(), [streamTwo()]) [ a, b | // do stuff with a and b ] It's admittedly isn't a totally nice syntax, but it's library and not a language feature, which is a huge plus IMHO.
Since the provider for the second closable does not take any arguments, the syntax would be even worse: tryWith( streamOne(), [|streamTwo()]) [ a, b | // do stuff with a and b ] Furthermore anything that is used by the constructor of streamTwo has to be final in the method body. Therefore I think it would be ok to use nested tryWith invocations for the rare case of having two closables at hand tryWith(streamOne()) [ first | tryWith(streamTwo()) [ second | .. do the hard work here ] ] Since we have sneaky throw for Xtend, it should work well enough: try { tryWith(newStream()) [ // this save the finally dance in the surrounding try ] } catch(IOException e) { // alert, log, do whatever you like } and it's not too bad compared to a first class support for new instances as 'argument' for the try block: try(newStream()) { // hardwork with 'it' } catch(IOException ioe) { // logging }
(In reply to comment #4) > Since the provider for the second closable does not take any arguments, the > syntax would be even worse: > > tryWith( streamOne(), [|streamTwo()]) [ > a, b | > // do stuff with a and b > ] That depends on how we define the signature ;-) > > Furthermore anything that is used by the constructor of streamTwo has to be > final in the method body. Since final is the default in Xtend anyway I don't consider this a problem. > Therefore I think it would be ok to use nested > tryWith invocations for the rare case of having two closables at hand > > tryWith(streamOne()) [ first | > tryWith(streamTwo()) [ second | > .. do the hard work here > ] > ] Looks good and is even simpler. :-)
Alternativly we could make this an implicit extension method instead of a tryWith(..) routine: new FileOutputStream(..).closeAfter [ // do something with *it* ] It would probably need a better name, though.
Yes, that's nice and I also like the name.
Alternatively we could use one of the operators, e.g new FileInputStream(myFile) => [ processStuff() ] or new Reader(..) >>> [ ]
We just talked about this some more and decided that we should go with the language feature instead of the library method, because: 1. The syntax gets awkward for more than one closable 2. Having more than one closable is pretty common (OutputStream => OutputStreamWriter => BufferdWriter) 3. The AutoClosable interface was only introduced in Java 1.7
+1 .. just found this, would be nice to have this now? In the mean time, https://github.com/dslmeinte/Xtend-utils/blob/master/Xtend-util/src/nl/dslmeinte/xtend/resources/ResourcesUtil.xtend looks neat.
I implemented try-with-resources in Jbase (https://github.com/LorenzoBettini/jbase/pull/60). If there's still interest in supporting try-with-resources in Xbase I can work on that (hopefully, it should be rather straightforward now that I know where to put my hands on :)
> If there's still interest in supporting try-with-resources in Xbase Hi Lorenzo, FYI I personally currently use Xtend less than I used to when writing the comment above - but generally speaking the feature still seems like a nice to have...
I often miss this feature...
see https://github.com/eclipse/xtext-xtend/issues/395
The GitHub issue is closed (https://github.com/eclipse/xtext-xtend/issues/395), I am simply closing this bug accordingly, if you don't mind 😀
