Re: Java language and library suggestions

From:

Tomas Mikula <tomas.mikula@gmail.com>

Newsgroups:

comp.lang.java.programmer

Date:

Sun, 19 Jul 2009 09:55:54 -0700 (PDT)

Message-ID:

<ccd2ae0a-4c3e-4801-ad27-b6beacdcbeb6@k19g2000yqn.googlegroups.com>

On Jul 19, 6:15 pm, Arne Vajh=F8j <a...@vajhoej.dk> wrote:

Tomas Mikula wrote:

On Jul 19, 4:42 pm, Arne Vajh=F8j <a...@vajhoej.dk> wrote:

Tomas Mikula wrote:

On Jul 19, 3:42 pm, Arne Vajh=F8j <a...@vajhoej.dk> wrote:

Tom Anderson wrote:

On Sun, 19 Jul 2009, Lew wrote:

Tomas Mikula wrote:

Anyway there are still many cases when one could use safely it =

to get

more readable code.

Arne Vajh?j wrote:

It can happen, but I don't think it occur frequently enough to
justify a feature that is so easy to misuse.

Tomas Mikula wrote:

I disagree again. Almost everything can be misused. If someone fe=

els

like their code never throws an exception, they could tend to wri=

te an

empty exception handler:
try {
// code that is incorrectly assumed not to throw any excep=

tion

} catch(Exception e) { }
If the Exception can actually be thrown and should be handled, th=

is is

very bad.
I guess that the following would be a much better (although still=

bad)

solution in this case.
@safe
// code that is incorrectly assumed not to throw any exception
So even if it's going to be misused, it could eventually restrain=

from

worse things.

"could" != "would".
The proposed language feature would be a change to the language th=

would be easy to misuse, might just possibly (if you're right) hel=

ever-so-slightly in some corner cases, in order to save a little b=

of typing. It doesn't seem like a good tradeoff. Just write =

the damn

exception handler and quit complaining.

This *is* an exception handler! It's shorthand for:
try {
STATEMENT
}
catch (EXCEPTION e) {
throw new AssertionError(e);
}
How is that not an exception handler?

It is an exception handler.
But it is converting the exception that the designer of the API
being called consider a real possibility to an exception that should
never happen by the designer of the calling code.

The designer of the API may as well state that the declared exception
will only be thrown under certain circumstances. If I avoided these
circumstances, then the exception won't be thrown. I will provide an
example:
class WriterEncoder {
   public WriterEncoder(Writer w);
   /** @throws IOException if and only if the write() methods of
underlying Writer throw an exception. */
   public void writeEncoded(MyClass obj) throws IOException;
}
Now if I construct the WriterEncoder with StringWriter which does not
throw IOException on write, I can be sure that
WriterEncoder.writeEncoded() won't throw IOException either.

Yes.

But it is very bad code.

The safe construct is relying on knowledge about implementation
of both the calling and the called code instead of just relying
on the exposed API's.

So what would be your solution? The task is (continuing on the above
example) to write a method for which it does not make sense to throw
an IOException. Yet it is advantageous to use WriterEncoder with
StringWriter from within this method. The best solution I can think of
is

try {
encoder.writeEncoded(obj);
} catch(IOException e) {
throw new AssertionError(e);
}

which is exactly what could be written more concisely with @safe.

I would either catch the exception and do something to handle
the situation properly

From the beginning I'm talking about situations when throwing an error
is the most proper handling of the situation.

or let the exception bubble to where it
could be handled properly.

As I noted in the example, bubbling of the exception would be a
logical error - getting an IOException from a method that by
definition does not do any I/O.

I would not tie my code to an implementation.

That is a pretty serious decision. It makes sense to me that it
requires some rather explicit coding.

It *is* a serious decision and the outcome of that decision could be
using the @safe construct.

Given that the most common damn exception handler the typical progr=

ammer

would write after quitting complaining would be:
try {
STATEMENT
}
catch (EXCEPTION e) {} // good luck debugging this

We need to decide whether we want to design Java after
making it easy for college students in the first months
of programming or whether we want to design a language
for real usage.

The main idea of the proposed construct is not making the code easier
to write (although that is another benefit), but making the code
easier to read (for everyone, not just college students).

For exception handling a catch block is very readable.

Well-known Java conecpt. Well-known in a lot of other OO
languages as well.

Yes, try-catch block alone is readable. But what about the method that
contains a couple of try-catch blocks?

Just as readable.

Especially if your other suggestion about multiple exceptions in
a single catch were added.

I disagree, but am not going to post another example to demonstrate
the readability improvement. Everyone can think for themselves.

Tomas