Re: can't throw
Robert Klemme wrote:
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.
I am not surprised. Unfortunately, I never learned that.
Beginning Java texts that I have seen do not cover it. With BASIC,
Here you go, the cure for your ignorance of how to use Java exceptions:
http://docs.oracle.com/javase/tutorial/essential/exceptions/index.html
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 (!)
It isn't if you read the tutorial.
The place where everyone is recommended to begin learning Java.
mechanism is pretty simple: exception handler order matters: the first
matching handler is used. So you can place handlers for classes down
From the tutorial: " The runtime system invokes the exception handler
"when the handler is the first one in the call stack whose ExceptionType
matches the type of the exception thrown."
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.
As illustrated in the tutorial: "By catching any IOException that's not caught
by the first handler, . . . "
I find the distinction between checked and unchecked exceptions pretty
good - although the distribution of exception types across these
"The first kind of exception is the checked exception. These are exceptional
conditions that a well-written application should anticipate and recover from."
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.
Unless they read the tutorials.
Maybe, it was too much of trying to be everything to everybody?
Maybe it was a case of not RTFM?
Blaming the language for one's failure to study is an unworthy act.
I believe what you describe is rather an effect of the massive success
This doesn't apply to exceptions, most of whose functionality has been
the same in Java for a long time.
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.
But learning about Exceptions isn't an API exercise, at this level, but
a language-comprehension issue and whether one bothers to read the
elementary introductions to the language.
Or then whines that the language is too hard because they didn't bother
to learn the most elementary aspects of it in the first place.
--
Lew