Re: can't throw
On 14.09.2012 22:16, Gene Wirchenko wrote:
On Fri, 14 Sep 2012 20:50:38 +0200, Robert Klemme
<shortcutter@googlemail.com> wrote:
On 14.09.2012 18:49, Gene Wirchenko wrote:
It may not be nearly as elegant, but I still prefer BASIC's ON
ERROR GOTO handling. Yes, one had to sort through the error numbers,
but that made it easier in some ways. One could code something to
handle the few cases where there was a specific handling and then use
a catch-all for the rest.
Well, you can do _that_ in Java, too.
I am not surprised. Unfortunately, I never learned that.
Beginning Java texts that I have seen do not cover it. With BASIC,
handling errors was with only one error handler so it was forced to do
it that way (and sometimes, it was covered).
I wasn't aware that this seems to be such a mystery. The basic (!)
mechanism is pretty simple: exception handler order matters: the first
matching handler is used. So you can place handlers for classes down
the exception inheritance hierarchy at the front and place handlers for
classes further up later. In an extreme case use a catch block with
RuntimeException, Exception or Throwable as last one.
I find the distinction between checked and unchecked exceptions pretty
good - although the distribution of exception types across these
categories does not always seem to be wisely made in the standard library.
Java has too many distinctions that are not easily (or
often-enough) made and that can catch Java newbies.
Maybe, it was too much of trying to be everything to everybody?
I believe what you describe is rather an effect of the massive success
the language has had. That success a) led to a prolonged life and b)
steered more resources into the development of the language, libraries
and frameworks. For another language people might not have bothered to
write another IO library. Now there are is more than one around to
maintain compatibility and that makes the language look inconsistent -
even though it's just history showing. Same story with Vector and
ArrayList or synchronized vs. java.util.concurrent.locks (where one is
really a language feature and the other a library) or Date vs. Calendar.
As Lew said, you need darn good library designers to get it right the
first time. But at least you can see that newer parts of the library
are better than older parts. I find that good even though it increases
the volume of library API to learn.
Cheers
robert
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/