Exception handling with ARM blocks

One of the big questions in my mind around ARM blocks is exactly how they should behave when exceptions are thrown while disposing of managed resources. It seems likely that we'd want some flexibility in this - there are probably cases where we'd like the ARM block to suppress these exceptions, but others where that would be inappropriate.

The initial version of the prototype only supported the do() { } form of ARM block, and forced the programmer to catch any checked exceptions thrown by the resources' close() methods, which I've found generally leads to wrapping the do() block in a try { ... } catch (IOException e) { ... }, or adding throws IOException to the enclosing method's signature, neither of which is necessarily useful.

Build 03 changes the default semantics of the do() block so that it no longer throws exceptions raised by calling the close() method, and adds support for a try() form of ARM block which can be used when the programmer does wish to explicitly handle such exceptions.

So in the following example using Closeable resource 'fooFactory' , there's no longer any need to provide explicit handling of IOExceptions:

do (fooFactory) {
    System.out.println("innocuous");
}

whilst this code forces us to catch exceptions of type FooException, which is a checked exception:

do (fooFactory) {
    Foo foo = fooFactory.createFoo();
    if (foo == null)
        throw new FooException("no foo :(");
}

and the new try() block allows us to do that more neatly:

try (fooFactory) {
    Foo foo = fooFactory.createFoo();
    if (foo == null)
        throw new FooException("no foo :(");
}
catch (FooException e) {
    // something went wrong in the block
}
catch (IOException e) {
    // something went wrong disposing of fooFactory
}

A further option for the try() block would be to suppress any exceptions thrown during automatic disposal which are not explicitly caught, allowing us to choose which ones we wish to handle. This doesn't seem quite so nice if the main body of the try block also throws IOExceptions though.

Thoughts welcome.

CICE/ARM prototype

As I mentioned a few days ago, I've been hacking around in javac recently in an attempt to get it to implement some of the ideas in the CICE and ARM proposals. The idea being that having a prototype available may help to highlight which aspects of the proposals really work in practice, and which do not.

I've put an initial cut here, which is based on the JRL licensed JDK codebase from 04-Dec-2007 (JDK 7 build 24). It hasn't had a great deal of testing, so don't expect it to be wonderfully stable at this stage. I'll attempt to fix any bugs that crop up however.

It's important to note that this initial prototype has been put together without consulting the authors of the two proposals, so I may well have misunderstood some of the ideas - apologies if so. I've also had to make a call on which aspects of the proposals to include, and which to exclude for now. I've opted for a pretty minimalist implementation to start with, and that pans out as follows:

CICE

CICE expressions, public local variables and implicitly final local variables should all be working. I've left out transient public locals and type inference.

At this stage, I also haven't provided any of the library additions or changes mentioned in section IV of the proposal.

Basically all of the examples in the CICE document should work (apart from those involving AbstractThreadLocal).

ARM blocks

ARM blocks can take one of two forms, both based on the do keyword only for now. The first allows you to declare the resources' variables as part of the ARM block itself:

    do (InputStream in = new FileInputStream(src);
        OutputStream out = new FileOutputStream(dest)) {
        // ...
    }

The second form is where the resources are provided as a list of expressions:

    InputStream in = new FileInputStream(src);
    OutputStream out = new FileOutputStream(dest);

    do (in, out) {
        // ...
    }

Currently, all resources must implement java.io.Closeable. As the ARM proposal points out, Closeable is probably not a good choice in the long run, but it's a starting point.

An ARM block will attempt to call close() on all the resources, in the reverse order that they were listed. In the first form of the block the variables are not final so it is possible to reassign in and out to some other Input/OutputStream within the ARM block - the block will attempt to close whatever Closeables the variables refer to at the time the block ends. In the second form of the block, reassigning in and out has no effect.

In the first example, if in or out are set to null this effectively cancels the automatic closing of the variable in question, and does not cause a NullPointerException or any other runtime error. I don't know whether this is useful or not, as yet.

In the first form, it's possible to mark the variables as final. It's also possible to mark them as public, which is only really useful if reassignment should be allowed.

If exceptions are raised, whether by evaluating the variable initializers (in the first form), by executing the body of the block, or by the calls to close() at the end of the block, it should only ever be the first such exception which is ultimately thrown by the block, after it has attempted to close all the resources.

The proposal doesn't mention whether it should be possible to use 'break' statements within an ARM block so I haven't implemented that. I think it may be useful though - thoughts welcome.

Bug reports and the like can be sent to me directly at markmahieu at gmail dot com.

CICE/ARM observations

When looking at a proposed new language feature it's often useful to compare it against similar features in other languages, and against alternative proposals. Such comparisons can lead to a deeper understanding of the opportunities and pitfalls involved, and this certainly holds true in the case of adding closures to Java.

Neal Gafter has made available a prototype implementation of a large chunk of the BGGA specification, which was immensely helpful in my own attempts at understanding that proposal. However, Josh Bloch's recent comments on the closures debate caused me to think that it would be useful to have a similar prototype of the CICE and ARM proposals as a more concrete basis for comparison, so over the last couple of weeks I've attempted to put one together (it makes a change from the day job). The result is that I now have a version of javac which implements one interpretation of CICE/ARM.

A number of observations about both CICE/ARM and BGGA have come out of building and using this thing, and I'll blog about some of them over the coming days. For now, I'll start off with a couple of quick comments:

Firstly and most importantly, both the CICE and ARM documents really are 'a bit sketchy' (to quote Josh Bloch) in places - the ARM document in particular, which covers a good many of the possible options and issues within its chosen design space, but seems to stop short of making a call on some of the more important ones (this is why I say I've implemented 'one interpretation' of them). There seem to be quite a few valid possibilities when you combine the options for resource acquisition/initialisation/disposal and exception handling, and there's no obvious 80/20 rule apparent to me at least. In comparison, BGGA avoids such issues largely by being more open and flexible about these options, and therefore not having to specify them.

Something I didn't expect was that 'this' within a CICE doesn't mean what I subconsciously expect it to when writing code - I find myself thinking it means the instance of the containing class, not of the CICE itself. Maybe it's because of the shorter syntax, or the fact that I've been using BGGA recently, although I do get this problem with normal anonymous classes in Java from time to time anyway.

Finally (and I'm not sure about this one yet) I have a suspicion that the current syntax for a CICE could be a bit tricky to parse if you want to stick to one-token lookahead, possibly involving a fair bit of messing with the grammar which javac is based on.

More later.