Re: Java language and library suggestions

From:

Tomas Mikula <tomas.mikula@gmail.com>

Newsgroups:

comp.lang.java.programmer

Date:

Sat, 18 Jul 2009 19:30:42 -0700 (PDT)

Message-ID:

<51347d23-6da1-497e-bcb0-1a28134c31a7@h18g2000yqj.googlegroups.com>

On Jul 19, 2:54 am, Arne Vajh=F8j <a...@vajhoej.dk> wrote:

Tomas Mikula wrote:

On Jul 19, 2:27 am, Arne Vajh=F8j <a...@vajhoej.dk> wrote:

Tomas Mikula wrote:

On Jul 19, 1:08 am, Arne Vajh=F8j <a...@vajhoej.dk> wrote:

Tomas Mikula wrote:

On Jul 18, 9:08 pm, Arne Vajh=F8j <a...@vajhoej.dk> wrote:

chucky wrote:

4. Sometimes having to catch an exception that will never be thro=

wn is

really annoying.
For example, I would like to write something like
@safe
URI uri = new URI("http://valid.uri.com/");
instead of
URI uri;
try {
uri = new URI("http://valid.uri.com/");
} catch(URISyntaxException e) {
throw new AssertionError(e);
}
I used the annotation notation, but I doubt something like this c=

an be

achieved with annotations. It would be nice if the language had a
construct to mark some code exception safe and if it threw an
exception, it would result in AssertionError. It could also be mo=

flexible, like this
@safe(NumberFormatException, UnsupportedEncodingException)
{
// statement that should not throw any NumberFormatExcepti=

on or

UnsupportedEncodingException
// and if it does, it is an AssertionError
}

I don't like that idea.
It is relative rare that you will need that (because even though t=

code may not throw the exception now, then it may in the future), =

I think it is OK to ask people to explicit code for it.

Did you mean that the number format, url format, ... may change and
previously valid values will become invalid?
If so, I want to do the same thing, let my program crash, but witho=

the extra code needed.
Maybe I didn't explain it clearly the first time. I didn't mean tha=

no exceptions would be checked within the code marked with @safe.
Rather if an exception in such code occured, AssertionError would b=

thrown.

The problem is that your code is demo code.
In real code you typical have an interface that declares
a throw exception.
And even though you may know tat the current implementation
code will never throw the exception, then another implementation
in the future may.

That doesn't change anything. Maybe I chose a misleading name. Maybe =

should have chosen @assert instead of @safe.
Then
@assert any_statement;
means that I make an assertion that any_statement will not throw any
exception. And if it does, it is an AssertionError.
And if the semantics of any_statement changes in the future, it's
still an AssertionError.
Consider the example:
int i;
try {
i = Integer.parseInt(valid_int_string);
} catch(NumberFormatException e) {
throw new AssertionError(e);
}
What you say means that I should not throw AssertionError, because in
the future the code could really throw the NumberFormatException. But
if it does, I still want to get the AssertionError, because
continueing without the correct value in i does not have any sense.
As with everything, the use of @safe (@assert) would be a deliberate
decision of the programmer.

The new code snippet is still demo code and does at all cover
what I was talking about: interfaces.

If a method in an interface is declared to throw an exception
then it is a clear statement that it may happen either now or
in the future.

Assertions is something that is expected never to happen.

Converting exceptions to assertions in such a case is a severe
violation of OO principles.

Then one would not use the proposed @safe directive in that case. I
didn't suggest to use it any time it seems that the code does not
throw exceptions.
Anyway there are still many cases when one could use safely it to get
more readable code.

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

Arne

I disagree again. Almost everything can be misused. If someone feels
like their code never throws an exception, they could tend to write an
empty exception handler:

try {
// code that is incorrectly assumed not to throw any exception
} catch(Exception e) { }

If the Exception can actually be thrown and should be handled, this 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.

Tomas

Tomas