Re: Java language and library suggestions
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
---910079544-1567095140-1248001075=:13702
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT
On Sat, 18 Jul 2009, Tomas Mikula wrote:
On Jul 19, 1:08?am, Arne Vajh?j <a...@vajhoej.dk> wrote:
Tomas Mikula wrote:
On Jul 18, 9:08 pm, Arne Vajh?j <a...@vajhoej.dk> wrote:
chucky wrote:
4. Sometimes having to catch an exception that will never be thrown
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);
}
It is relative rare that you will need that (because even though the
code may not throw the exception now, then it may in the future), so
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?
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.
For the vast majority of exceptions, this is true. The problem is that
there are a small number of checked-exception-throwing expression where it
is not true. Constructing a URL from a known-good literal string is one;
constructing an InputStreamReader with a known-good charset name (eg
UTF-8, which the spec always requires to be available) is another. In both
those cases, i would say that providing a bad URL or a bad charset name is
a programmer error, and thus the kind of thing that should get a runtime
exception, not a checked exception.
Rather than taking that as an argument for an @safe construct (@assert is
a terrible name for it, by the way, so let's keep calling it @safe -
@AssertSafe would perhaps be even better), i think it's an argument that
the library design is wrong - those methods should be throwing runtime
exceptions, not checked exceptions.
The problem, of course, is that the same methods are also used with
not-known-good values for URLs and charsets which come from outside the
source code, and thus are vulnerable to not-programmer-error failure,
which should elicit a checked exception after all.
Perhaps we should just declare that it's the programmer's job to check the
arguments, and use runtime exceptions anyway.
Perhaps there should be two variants of each of these methods, one which
throws a checked exception and one which doesn't. Except then you just
know that programmers will call the version without the checked exception
even with external parameters, and we're back to just having an unchecked
version.
Maybe literal strings should have a different type to strings that came
from data. Perhaps something like smalltalk's 'symbol', except that there
would be no way to make a symbol from a string. There could be a version
of the method which took a string and threw a checked exception, and a
version which took a symbol and didn't. This is obviously getting a bit
mental, though.
As far as the InputStreamReader example is concerned, a more OO solution
would be to use the version of the constructor which takes a Charset
rather than a charset name, which doesn't throw an exception - if you have
a Charset object, then you know you have a valid charset, so there's no
need. You can get a Charset object from Charset.forName without having to
deal with a checked exception - i think you shouldn't be able to, but you
can. Why there aren't constants on Charset for the six standard charsets,
i really don't know.
I can't think of an equivalent to this for creating URLs. It's not as if
you can have constants for all valid URLs, is it? You could add a constant
to your own class for the URL in question, but you still get a
MalformedURLException in defining it. This is where Tomas's idea comes in
useful:
@AssertSafe(MalformedURLException.class)
public static final URL u = new URL("http://www.example.com/");
I'm not sure if you can do that with an annotation - suppressing an error
rather than a warning? - but we want something along those lines. Maybe it
should be some harder bit of syntax, although i can't see a suitable
keyword, and i'd be loath to add a new one.
That doesn't change anything. Maybe I chose a misleading name. Maybe I
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.
Since NumberFormatException is a runtime exception, this is a bad example.
tom
--
Infantry err, infantry die. Artillery err, infantry die. -- IDF proverb
---910079544-1567095140-1248001075=:13702--