On Jul 19, 3:42 pm, Arne Vajh?j <a...@vajhoej.dk> wrote:
Tom Anderson wrote:
On Sun, 19 Jul 2009, Lew wrote:
Tomas Mikula wrote:
Anyway there are still many cases when one could use safely it
to get
more readable code.
Arne Vajh?j wrote:
It can happen, but I don't think it occur frequently enough to
justify a feature that is so easy to misuse.
Tomas Mikula wrote:
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.
"could" != "would".
The proposed language feature would be a change to the language that
would be easy to misuse, might just possibly (if you're right) help
ever-so-slightly in some corner cases, in order to save a little bit
of typing. It doesn't seem like a good tradeoff. Just write the
damn
exception handler and quit complaining.
This *is* an exception handler! It's shorthand for:
try {
STATEMENT
}
catch (EXCEPTION e) {
throw new AssertionError(e);
}
How is that not an exception handler?
It is an exception handler.
But it is converting the exception that the designer of the API
being called consider a real possibility to an exception that should
never happen by the designer of the calling code.
The designer of the API may as well state that the declared exception
will only be thrown under certain circumstances. If I avoided these
circumstances, then the exception won't be thrown. I will provide an
example:
class WriterEncoder {
public WriterEncoder(Writer w);
/** @throws IOException if and only if the write() methods of
underlying Writer throw an exception. */
public void writeEncoded(MyClass obj) throws IOException;
}
Now if I construct the WriterEncoder with StringWriter which does not
throw IOException on write, I can be sure that
WriterEncoder.writeEncoded() won't throw IOException either.