Automatic Resource Management, V.2
scolebourne at joda.org
Mon Apr 20 10:24:11 PDT 2009
2009/4/20 Joshua Bloch <jjb at google.com>:
>> Why not return a List<Throwable> instead of an array (since
>> Collections are generally nicer to use)?
> I did think about this, but I opted to stick with the pattern in enum types'
> values() method. That decision was made for performance. Arguably the
> performance issues are less important here, and the winds of change have
> blown further away from arrays since then, so I'm definitely open to
> switching this to a List if others think it's the right thing to do.
Definitely List. Arrays should be considered a deprecated type in all
JDK arrays at this point IMO. We need to move beyond thinking about
raw performance as a reason.
For example, I would have much preferred Enums to have had a Map of
name to enum as a generated method. I currently have to have a code
generator create this for every enum I write.
>> > The printStackTrace method should be modified to append the stack traces
>> for any suppressed exceptions.
>> This might be difficult, particularly where there are a number of
>> "cause" and "suppressed" exceptions (each of which might have their
>> own) - it might be hard to associate each exception with its parent in
>> the output (whereas currently "cause" has only one immediate parent
>> and so it is easy to follow such a stack trace).
> I did think about this, and came to the conclusion that it wasn't so bad.
> The main problem is the "intermingling" of causes and suppressed
> exceptions. I will come up with a format and put an example in the spec.
The proposal should strive to include enhanced stack traces.
> > (More generally, I think I'd prefer a single resource per ARM, as I
> > think its a lot clearer overall and more consistent, but since you've
> > allowed it in the proposal, I assume you'd want to keep to that
> > style.)
> Yes. May people really care about keeping the nesting depth low, and
> the ability to combine resources in a single ARM statement does that for them.
In my own work, I would probably choose to go with a code convention
requiring each ARM block to only have a single declaring variable.
More information about the coin-dev