Re: Java language and library suggestions

From:

=?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk>

Newsgroups:

comp.lang.java.programmer

Date:

Sun, 19 Jul 2009 21:44:19 -0400

Message-ID:

<4a63cbf1$0$48240$14726298@news.sunsite.dk>

Tomas Mikula wrote:

On Jul 20, 1:52 am, Arne Vajh?j <a...@vajhoej.dk> wrote:

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.

And this is the case I want the program to crash. It is reading the
configuration during initialization and the configuration contains
invalid value. I get an error, fix the configuration and run again.

But you do not get the exception you should.

You get an assertion error.

And if you don't want your program to crash in this situation, noone
forces you to use this construct.

No. But little point in adding features to the language that
are not really needed just because people do not need to use
them.

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

No, not the same benefits. It has its own benefits.

Let me rephrase: it does not carry benefits in the same order
of magnitude as exceptions and checked exceptions.

But the talk here
is about misuse, not benefits. And misused @Safe would usually do less
damage than misused try-catch.

You have to compare benefits with with drawbacks.

* misuse of this features is very difficult to find while
empty catch block is easy to find both visually and
with style checkers

I can't object, but compare it to construct that it is meant to
replace, i.e.
try {
safe_statement;
} catch(EXCEPTION e) {
throw new AssertionError(e); // or throw new RuntimeException(e);
}

How is misuse of @Safe more difficult to find than the misuse of this?

It is more difficult to spot.

And besides the construct itself is not very good in the first place.

Arne