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.