On 19/02/2012 00:48, Jonathan M Davis wrote:
On Saturday, February 18, 2012 16:46:43 H. S. Teoh wrote:
I can't believe something this simple has to be explained so
elaborately. I thought all of us here knew how to use OO??
I think that the problem stems from people frequently using exceptions
incorrectly, and many of the C++ programmers probably haven't _ever_ seen them
used correctly, since I don't think that it's very common for C++ programs to
define exception hierarchies - especially not advanced ones like Java has. And
when you see a lot of bad exception code, that tends to turn you off to them,
and it definitely doesn't show you how to use them correctly.
- Jonathan M Davis
I can assure you they get misused in Java too. Most people write this:
try {
lots and lots and lots of stuff here
}
catch (Exception e) {}
All they wanted to do was get round the compile error because they
called Thread.sleep() which throws InterruptedException which you're
required to catch, and they know they're never going to call
Thread.interrupt().
What they end up doing is catching NullPointerException,
ArrayIndexOutOfBoundsException and all the other things that really
matter, and nasty bugs can go undiagnosed.
Eclipse's auto-fix impoves things a little - it can generate this for you:
try {
...
}
catch (InterruptedException e) { //For example
//TODO: auto-generated catch block
e.printStackTrace();
}
But no one does their TODOs, and no one takes care to keep the console
output short enough to be useful.
You CAN write "throw new RuntimeException(e)", and you won't be required
to catch that one. And then exceptions are incredibly useful, and I've
even found rare cases where creating my own checked exception makes an
API much safer. (I was processing code, and I had something like an
'uninline' operation that occasionally couldn't work, so the caller had
to always have a backup plan in case the exception was thrown.)
So it could be a good system, but no one has any idea what they're doing
with it.
If I had to improve the Java one, I suppose I would:
- distinguish between 'bug' exceptions (e.g. null) and 'you're more
likely to want to catch this' exceptions (e.g. IO). Maybe the bug ones
should have been Errors, since people *usually* don't catch those (and
are certainly never required to). As it stands, Errors are reserved for
corrupt class files and other VM panic scenarios.
- make sure the 'lazy' approach is a good one: the less you type, the
fewer exceptions you catch, and the less likely you are to silence those
exceptions at runtime. Probably the main problem with the exception
hierarchy is that the short names tend to be the more general ones that
are more dangerous to catch indiscriminately.
