Received: by 10.224.42.68 with SMTP id r4mr2908921qae.4.1347658110130; Fri, 14 Sep 2012 14:28:30 -0700 (PDT) Received: by 10.52.175.5 with SMTP id bw5mr134044vdc.16.1347658110073; Fri, 14 Sep 2012 14:28:30 -0700 (PDT) Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!v8no3348714qap.0!news-out.google.com!da15ni55818832qab.0!nntp.google.com!v8no3348709qap.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.java.programmer Date: Fri, 14 Sep 2012 14:28:29 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=69.28.149.29; posting-account=CP-lKQoAAAAGtB5diOuGlDQk0jIwmH0T NNTP-Posting-Host: 69.28.149.29 References: <19af6b94-7a1e-4491-afb2-79782406f560@googlegroups.com> <504fe3a6$0$293$14726298@news.sunsite.dk> <50510bbc$0$281$14726298@news.sunsite.dk> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <8d3ef5fc-c5a5-4ebd-9762-aaca2de41289@googlegroups.com> Subject: Re: can't throw From: Lew Injection-Date: Fri, 14 Sep 2012 21:28:30 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Received-Bytes: 5277 Xref: csiph.com comp.lang.java.programmer:18779 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