Reinier Zwitserloot wrote:
> 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.
>
Fair enough. I keep forgetting about runtime exceptions, that's why I
like the checked ones :-)
[...]
>> 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?
>
The problem I see is that someone on a lower layer might have done this
and the guy on the layer above is not aware of it. I know you will
counter with the argument that the alternative is bad catches, and I
agree to some extent. But those catches you describe (the
e.printStackTrace() and similar) are known to be bad, adding a mechanism
to the language makes it look much more legit. Of course the new
RuntimeException(e) is much better, but I don't think it is a general
solution either.
>
>
>>> 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.
>
It doesn't seem right to add language features to deal with crappy
library design.
> 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.
>
What you are proposing seems to me like making a mediocre solution easy
to avoid people doing the really bad ones. Call me an idealist, but I
don't really like that.
Just think of the problem one layer above the one that may use the
sneaky throws: you might get some methods you call that pass the
IOException to you, some might do what I consider right and chain it
with their own checked exception and other just do the sneaky throw. To
figure out what's happening I really need to know the internals of each
method down to the bottom. The alternative is catch(Exception).
Admittedly the problem is already there since Java has both checked and
unchecked exceptions.
>>> 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.
No implementation would be duplicated, the safe version could be a
subtype of the unsafe one. Not too many interfaces will face that
problem. To me it seems much better than not distinguishing.
Peter
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
