On Monday, March 28, 2011 9:12:31 AM UTC+2, Casper Bang wrote:
>
> keywords. How about we simply loosen the chain a bit, making checked
> exceptions into warnings instead. IDE's and compilers will still
> complain, but now the busy programmer can stay on his primary train of
> thought without getting derailed.
Warning instead of error works fine. Suppressing this with
@SuppressWarnings() is a mistake, though. At the end of the day the point is
for your editor to tell you about it, and whether it does so by way of a red
wavy underline or a yellow one is not all that relevant. The problem with
this design is @SuppressWarnings annotations is that they are like
"@SneakyThrows(Throwable.class)" - there's no nuance here. Putting one of
these suppressWarnings annotations on for a perfectly legitimate reason now
also silently eats up any other checked exceptions. This leads right back to
the muscle memory problem - and thus the @SuppressWarnings option is not
much better than getting rid of all checked exception errors silently in the
first place.
This can be fixed of course; make unhandled checked exceptions a warning,
but instead of using @SuppressWarnings, create a new annotation that accepts
a list of class types:
@SuppressChecked(UnsupportedEncodingException.class)
public void whatever() {
.... something that throws UnsupportedEncodingException for no good
reason ...
}
--
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
