Re: Java language and library suggestions
Tom Anderson wrote:
On Sun, 19 Jul 2009, Lew wrote:
I don't see the saving of six lines of typing to be worth the burial
of this serious a decision.
And tom, while the proposed @Safe (obviously it wouldn't be "@safe")
"is" and exception handler under the hood, it doesn't look like one.
I espouse writing explicit exception handlers for checked exceptions.
The purpose of a checked exception is to require explicit handling.
To dodge that to save a few lines of typing ("Ow! My poor fingers!")
defeats that purpose,
This is not about typing, it's about reading.
This business about exception handlers being perfectly readable, and
thus a fine way of dealing with this situation, is nonsense. An
exception handler says to the reader "there is an exception which can
occur here, and this is how we deal with it". Here, we're talking about
exceptions which *cannot* occur. Writing catch blocks for them simply
serves to give the reader more to read, and once they've read it,
confuses them as to why it's there.
and as Arne points out, moves the realm of expected exception to
impossible error.
Have we been reading completely different threads? The whole point of
this is for situations where the exception *is* impossible. Or perhaps
you could explain to me how this line:
Reader r = new InputStreamReader(System.in, "UTF-8");
Is capable of throwing an IOException.
Not know.
But just:
Reader r = new InputStreamReader(System.in, strfrompropertiesfile);
is enough to break the guarantee.
It is not good to have code that breaks without compiler warnings
for simple code refactoring done above.
Instead of calling lazy programming "Java as it is" and a call to
improve coding practices putting one's head in the sand, if you become
a proponent of making Java (not "java") coding rigorous and
disciplined, that's what looks like a reasonable idea. Why promote
laziness, poor design and whining?
Firstly, i think that Tomas's proposal is an outright good one - it
would make code clearer and more concise where used appropriately. That
seems like the most important test of a language feature to me.
Secondly, i think that where it could be misapplied, it would be better
than the misapplication of other features (empty catch blocks) that
currently happens. That also seems like a pretty good test.
As states earlier, then the comparison with empty catch blocks
is not a very good comparison because:
* this features does not carry the same benefits as exceptions
and checked exceptions
* misuse of this features is very difficult to find while
empty catch block is easy to find both visually and
with style checkers
Arne