try/catch expression

[Lawrence Kesteloot]

Rats! I didn't think about what the expression would return. Dammit.
In my mind of course it just returns from the enclosing function, but
that's not okay in general. Thanks for analyzing it, sorry I didn't do
a better job.

I don't agree that this change would force all statements to be expressions.

And I don't like the sloppy "put the entire code of a function inside
a large try/catch block". I've seen it result in too many errors where
someone adds a throwing line in the middle and doesn't realize an
existing catch will do something other than what they'd want. Also any
resulting log message isn't as clear.

Lawrence




On Wed, Nov 11, 2009 at 10:24 AM, Reinier Zwitserloot
<reinier at zwitserloot.com> wrote:
> For what it's worth, the java standard way of doing this is generally to
> bundle both the file open operation as well as the reads (and, arguably, the
> subsequent close) into a single try block. Even ARM does this - the
> initializer expression is part of the node that contains the operations done
> on the ARM block, so if you catch exceptions on the initializer, then you
> also catch them on the body, unless the body has its own try block, which
> looks no less ugly than your snippet.
> Your proposal is vague. What, exactly, is returned from a try/catch
> expression if the catch block is triggered? An implicit 'null'? Something
> akin to BGGA's last expression in the block? That would be a rather large
> change, and, like BGGA, you have to separate accidental from explicit use,
> for example by having that weird 'last expression must not end with a
> semi-colon' rule.
> Assuming you fill in the holes, I think this idea is rather underwhelming.
> The thing you're trying to fix here isn't used all that often (bundling open
> with read is more common and can be done much simpler, especially with ARM),
> the workaround fix isn't all that ugly, so it's not a matter of enabling you
> to do something that is almost impossible with today's java, and finally,
> this feels extremely inconsistent. If try/catch becomes an expression,
> shouldn't for, while, do, if/else, and perhaps even synchronized, be
> expressions too?
> That would be a major, major change in how java works. Could be a good
> change, but such a proposal needs to be written up and analysed, and I have
> a feeling it's going to play havoc on the parser grammar.
> --Reinier Zwitserloot
>
>
>
>
> On Wed, Nov 11, 2009 at 7:10 PM, Lawrence Kesteloot <lk at teamten.com> wrote:
>>
>> One nice thing about having been on the coin-dev list is realizing
>> that I really like Java as it is. None of the proposals (including my
>> list comprehensions) have seem "worth it" (except ARM). But there's
>> one thing that repeatedly grosses me out, and bothers me more each
>> day:
>>
>>    Reader foo = new FileReader(filename);
>>
>> This throws an IOException. I want to keep my catch clauses nice and
>> tight, so I end up writing:
>>
>>    Reader foo;
>>    try {
>>        foo = new FileReader(filename);
>>    } catch (IOException e) {
>>        log.warn("Cannot open file \"" + filename + "\" (" +
>> e.getMessage() + ")");
>>        ...;
>>    }
>>
>> The duplication of "foo" smells bad and four lines of noise were
>> added. I would prefer a try/catch expression:
>>
>>    Reader foo = try new FileReader(filename) catch (IOException e) {
>>        log.warn("Cannot open file \"" + filename + "\" (" +
>> e.getMessage() + ")");
>>        ...;
>>    }
>>
>> I can't think of a change to Java that would please me more
>> day-to-day. Anyone else feel the same? Should I write this up for
>> JDK8?
>>
>> Lawrence Kesteloot
>>
>
>