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.