Replies inline. The problem is simply this: You think I was trying to
argue against checked exceptions in general. I wasn't. I was arguing
that the checked exception system isn't perfect, and therefore
programmers need to be given a tool to say to the compiler: I know
better than you. Stop whining.
More specific arguments follow below, inline.
On Aug 19, 12:56 am, Peter Becker <peter.becker...@gmail.com> wrote:
>
> > Runnable does not let you throw Exceptions. Anyone up for defending
> > this grievous API design? The amount of annoyance that this is caused
> > me is almost limitless.
>
> Where would that exception go?
The same place the RuntimeExceptions thrown by the runnable go. Your
argument only makes sense if Runnable was precluded from throwing -any
and all- exceptions. That's not true. What possible use is there for
someone invoking a Runnable (which after all stands for: I have no
idea what this does, other than run... something...) - to
differentiate between checked exceptions and unchecked exceptions? The
thing threw an exception. It doesn't matter what kind of exception was
thrown.
So, for Thread, that would be: The exception handler of that thread.
>
> It makes some sense to me. The servlet container cares only about the
> fact that the servlet failed, the question why is rather secondary on
> that level. You could also imagine that subtypes are used to distinguish
> the actual problem.
Sure, and if ServletException had a mechanism to specify certain extra
info (such as which error code and message to return), that would be
great stuff. But either way, a servlet container MUST handle *ANY*
exception falling out of a servlet (sneakyThrow, scala, jruby, jython,
any other non-java language on the VM, and mixing class files from
different compile runs can ALL result in a method throwing a checked
exception it didn't declare, so you already have to handle them!)
>
> If you just allow any exception to go through (e.g. by letting the
> methods throw Exception on the API level), programmers will forget to
> handle things they could handle.
Idiots write idiot code. But, okay, I'll roll with your argument: Then
why isn't there a mechanism to escape it? Why can't I say: Nono,
compiler, I did not forget anything, this is what I want. Shut your
yap. You're not really going to argue with me that there is no
inconvenience at all here, right?
>> InputStream.close() throws IOException. Nuff said.
>
> That only proves that exceptions are used badly in the JDK.
That "only" proves? The JDK abuses checked exceptions - That's a
pretty big deal! That's the whole point! That's why the language needs
an escaping mechanism.
The further damage caused by bad coders abusing the escaping mechanism
are, in my opinion, much, __much__ smaller than the potential further
damage that would no longer becaused because the mechanism is
available. The occasional explicitly supressed checked exception that
should have been handled is far less of a crime than code littered
with this abomination:
try {
something();
} catch ( IOException e ) {
e.printStackTrace();
//TODO Eclipse auto-generated this. The programmer never looked at
it again, logging to system.err is just about the worst thing you
could do here, and the original programmer only hit quickfix-add try
catch block because he couldn't throw it onwards because he's
implementing a servlet, or a runnable.
}
Sure, an idiot coded that. But we're all idiots some of the time, and
you yourself put 'idiots exist' on the table as a legal line of
reasoning.
>> FilterInputStream and FilterOutputStream's methods throw IOException,
>> but if I feed it a ByteArrayInputStream, or I let it filter into a
>> ByteArrayOutputStream, then an IOException can never happen.
>
> Which could be solved by having safe and unsafe versions of the interface.
>
Do you realize how much code duplication that would require? Exactly
_BECAUSE_ you can't circumvent checked exception checking, you'd
actually have to copy/paste every method. I cannot put into words the
insanity of a system that would _require_ you to copy/paste vast
tracts of code just to satisfy a system that is principally designed
to help code maintainance. Talk about bass ackwards. In practice, you
would most likely implement this by.... employing a sneaky throw hack.
I can scarcely imagine a better case for enshrining sneaky throwing
into the JLS, than this line of reasoning.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
