Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > can't throw

Reply
Thread Tools

can't throw

 
 
Lew
Guest
Posts: n/a
 
      09-14-2012
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.


And you can't do that with Java exceptions?

> Well, you can do _that_ in Java, too.


Ah, I thought so.

So what was that advantage of BASIC's approach again?

> 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.


API writing is a Dark Art, or rather a Dark Artish approach to programming generally.

It's arguably the best approach.

But designing the exception API is Darker Art.

People who complain about checked exceptions always take the client point of
view, and always blame Java.

(Counterexamples welcome.)

But if they are so bad, why do API writers opt to use them?

I know the answer. Do you?

Regardless, why blame Java for the API writer's choice?

As for comparing to other languages that don't have checked exceptions,
that's utter bullshit. Bullshit, I say.

You can't compare the API writer's choices when they don't have the same
options.

So writers of code in those other, lesser languages that don't have checked
exceptions resort to some other idiom, simply because the checked
exception idiom doesn't exist.

So of course it works, because they use the mechanisms that their
languages *do* provide. Duh, and double-duh.

Drawing the conclusion that checked exceptions aren't necessary,
given some other mechanism to accomplish equivalent goals,
is hardly insightful. Drawing the conclusion from that evidence that
checked exceptions are somehow inferior to those other mechanisms
is fallacious.

What is valid is to compare decisions to use or not use checked
exceptions in environments where they are available.

Interesting then, that in such environments that good programmers
find checked exceptions useful.

If you don't like their insistence that you honor the exception contract
they designed, don't use their libraries. Just like if you don't like their
insistence that you honor the argument contract they designed, don't
use their libraries.

Just don't blame Java for providing the API writer the tools to force you
to deal with something they thought important enough to force you to
deal with. Thank God and the Java Founders that checked exceptions
were available to that API writer to enforce that contract on you, otherwise
a) they couldn't ensure you honor certain robustness requirements, and
b) you couldn't be sure of exactly what exceptional situations they really
insist you handle.

--
Lew
 
Reply With Quote
 
 
 
 
Gene Wirchenko
Guest
Posts: n/a
 
      09-14-2012
On Fri, 14 Sep 2012 20:50:38 +0200, Robert Klemme
<(E-Mail Removed)> 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 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?

Sincerely,

Gene Wirchenko
 
Reply With Quote
 
 
 
 
Gene Wirchenko
Guest
Posts: n/a
 
      09-14-2012
On Fri, 14 Sep 2012 13:02:05 -0700 (PDT), Lew <(E-Mail Removed)>
wrote:

>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.

>
>And you can't do that with Java exceptions?
>
>> Well, you can do _that_ in Java, too.

>
>Ah, I thought so.
>
>So what was that advantage of BASIC's approach again?


It is obvious that you can do it that way.

[snip]

Sincerely,

Gene Wirchenko
 
Reply With Quote
 
Robert Klemme
Guest
Posts: n/a
 
      09-14-2012
On 14.09.2012 22:16, Gene Wirchenko wrote:
> On Fri, 14 Sep 2012 20:50:38 +0200, Robert Klemme
> <(E-Mail Removed)> 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/
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      09-14-2012
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/tutori...ons/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
 
Reply With Quote
 
Robert Klemme
Guest
Posts: n/a
 
      09-16-2012
On 09/15/2012 12:33 AM, Leif Roar Moldskred wrote:

> Personally, I think it was a design flaw to tie the checked /
> unchecked to the class hierarchy. An exception's class corresponds to
> a particular error type, but the severity of a particular type of
> error, and wheter we can expect the client to be able to recover from
> it or not, depends on the context.
>
> The choice of checked / unchecked should be made statically _at the
> point of the throw statement_,


Let's see what the consequences of this would be:

1. we need new syntax (e.g. a new keyword), in order to make that
distinction. So it's either
throw checked new IllegalStateException("You can't do that right now.")
throw_checked new IllegalStateException("You can't do that right now.")

2. The complier needs to enforce all exceptions thrown with "throw
checked" are declared in the throws clause.

OK so far, no issues there.

3. Now, assume we have a section of code which throws the same exception
type checked and unchecked. That section is embedded in a try block.
Now we have a catch clause for this exception type attached to the try
block. This prompts the question: which of the thrown exceptions does
the catch block handle - only the checked throws or also unchecked throws?

3a. It handles both. This leads to the unsatisfactory situation where
the same catch block needs to handle programmer errors (now
RuntimeException and subclasses) and other errors which are actually
expected. That's not good since programmer errors (and catastrophic
situations like OOM are usually handled quite close to Thread.run, i.e.
further up the call stack.

3b. The programmer can decide, so we need a new syntax again:

catch checked ( IllegalStateException e )

This will only catch checked exceptions. Do we now need an additional
syntax for "unchecked", e.g.

catch unchecked ( IllegalStateException e )

And what do we do if we want to cover both cases (e.g. because we just
want to print the error)? Do we then do this?

catch checked, unchecked ( IllegalStateException e )

Or do we use the current form to mean "catch both"?

catch ( IllegalStateException e )

In which way we resolve these questions it's obvious that one can easily
forget a keyword or make a different error so one ends handling other
exceptions than intended.

Given the fact that the type of exception also describes the type of
error and that in turn is related to the classification "programmer
error" / "no programmer error" I am not so sure whether the additional
complication your distinction at call site introduces is actually
worthwhile.

Kind regards

robert
 
Reply With Quote
 
Robert Klemme
Guest
Posts: n/a
 
      09-16-2012
On 16.09.2012 19:17, Leif Roar Moldskred wrote:

> Plain catch statements, "catch ( SomeException ex )", only catches
> checked exceptions and it's illegal to have a plain catch statement
> for an exception that can not be thrown (checked) in the try
> block.
>
> "Catch unchecked" catches both checked and unchecked versions of the
> exception. Having only an unchecked catch for a given exception that
> can be thrown checked in the try block is legal, but causes a compiler
> warning: the preferred is to have two separate catch statements for
> checked and unchecked versions of that exception.
>
> It's not foolproof (fools are just so darned clever at times), but it
> strikes me as safe enough to be practical.


My point was not that it can't be made "safe". I rather questioned
whether the additional complexity introduced in the language would be
beneficial (even if we let compatibility issues aside for the moment).

Cheers

robert

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
 
Reply With Quote
 
Gene Wirchenko
Guest
Posts: n/a
 
      09-17-2012
On Fri, 14 Sep 2012 14:28:29 -0700 (PDT), Lew <(E-Mail Removed)>
wrote:

[snip]

>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.


Just try finding the most elementary aspects in all that bloat.

The problem is not so much reading the docs; it is finding the
correct ones. When one is just starting, it is difficult to sort the
wheat from the chaff.

Sincerely,

Gene Wirchenko
 
Reply With Quote
 
Gene Wirchenko
Guest
Posts: n/a
 
      09-17-2012
On Sun, 16 Sep 2012 22:36:00 +0200, Robert Klemme
<(E-Mail Removed)> wrote:

[snip]

>My point was not that it can't be made "safe". I rather questioned
>whether the additional complexity introduced in the language would be
>beneficial (even if we let compatibility issues aside for the moment).


The architecture astronauts got Java long ago.

While C has many trade-offs that I disagree with, one thing that
they got right is that it is a small language.

Sincerely,

Gene Wirchenko
 
Reply With Quote
 
Robert Klemme
Guest
Posts: n/a
 
      09-17-2012
On 17.09.2012 05:07, Gene Wirchenko wrote:
> On Sun, 16 Sep 2012 22:36:00 +0200, Robert Klemme
> <(E-Mail Removed)> wrote:
>
> [snip]
>
>> My point was not that it can't be made "safe". I rather questioned
>> whether the additional complexity introduced in the language would be
>> beneficial (even if we let compatibility issues aside for the moment).

>
> The architecture astronauts got Java long ago.
>
> While C has many trade-offs that I disagree with, one thing that
> they got right is that it is a small language.


But "small" is not a value in itself. Programming languages are tools
and a small language might have less complexity than necessary to solve
today's problems. If you can learn it fast (because it is small) but
then you need to go through hoops every day to write the code that you
need to write, what have you gained?

Cheers

robert

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
To throw or to throw not? Emanuele D'Arrigo Python 6 11-15-2008 04:12 PM
clocking muxing, plz throw some light sudeepts@gmail.com VHDL 1 02-23-2006 06:43 PM
JNI's throw new does not throw an exception yarona@m-sys.com Java 15 09-08-2005 08:36 AM
throw an application wide event in an asp.net page PrashanthNagaraj ASP .Net 2 11-24-2003 12:48 AM
Throw Exception Vs Throw New Exception Kerri ASP .Net 2 10-27-2003 02:13 PM



Advertisments