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);
}
I used the annotation notation, but I doubt something like this can 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 more
flexible, like this
@safe(NumberFormatException, UnsupportedEncodingException)
{
// statement that should not throw any NumberFormatException 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 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?
If so, I want to do the same thing, let my program crash, but without
the extra code needed.
Maybe I didn't explain it clearly the first time. I didn't mean that
no exceptions would be checked within the code marked with @safe.
Rather if an exception in such code occured, AssertionError would be
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 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.
As with everything, the use of @safe (@assert) would be a deliberate
decision of the programmer.
what I was talking about: interfaces.
in the future.
Assertions is something that is expected never to happen.