[3180] in java-interest
Re: java-interest-digest V1 #244
daemon@ATHENA.MIT.EDU (larrys@zk3.dec.com)
Thu Nov 2 14:52:54 1995
From: larrys@zk3.dec.com
To: java-interest@java.sun.com
In-Reply-To: Your message of "Wed, 01 Nov 95 21:55:34 PST."
<199511020555.VAA18567@java.sun.com>
Date: Thu, 02 Nov 95 10:54:35 -0500
Thomas.Ball@Eng.Sun.COM (Thomas Ball) wrote:
>Basically, there are two groups of errors: those you can reasonably
>recover from and those you can't. Opening a file is something an
>application can frequently recover from, but handling a protection
>fault normally isn't. Yes, in theory any error is recoverable, but the
>cost of trapping that error may outweigh the benefits of recovery. A
>RuntimeException (if I understand it correctly) is an error whose cost
>of checking for it outweighs the benefit of catching it.
>For example in Java, trying to catch errors with every possible memory
>allocation is difficult (new objects get allocated all over the place),
>so running out of memory is considered a RuntimeException. You can't
>do much of anything at this point anyway, so just say bye-bye.
>Checking for null pointers is also expensive -- to add checks each
>place an object is dereferenced in Java would be an incredible
>performance hit. In both cases, the costs outweigh the benefits.
This is simplistic and dangerous. It smacks of the kind of
"pragmatism" that gave the world C. I must say I disagree with
it with all my heart.
It is true that there are recoverable and unrecoverable errors -
the problem is, it cannot be safely determined which are which
until the design of the application is taken into account. By presuming
beforehand without this knowledge, you will merely make the language
unsuitable for use with applications of certain designs. We already
have enough languages with that problem, C foremost among them.
Running out of memory is classic case in point. Many GUI programs
will operate multiple windows and running out of memory while open-
ing a new one is a very common error. Killing the whole program
because it failed to allocate memory for some data structure needed
by a new window is user-hostile in the extreme. Far better to catch
the exception, back out of the new window operation, and allow the
user to close some other windows before trying again. To simply
blast the program out of the water because memory errors are "un-
recoverable" is just unacceptable. They _are_ recoverable, but it
is true that we cannot presume to know the solution before the
application is written. That's what exceptions are _for_.
As for checking every pointer dereference, that is something that
simply _must_ be done, for if it is not, then the first time we
dereference a null pointer we will have created a situation from
which the runtime system probably _cannot_ recover, and again the
program has died, and this is unacceptable. Or even worse, we will
have set up the conditions for serious data corruption and crashes
later on, when the cause will not be so obvious. Far better to just
put up a dialog that announces "Sorry, some internal error has
occured" and give the program a chance to clean up its state and
return to a known one, or at least one from which a save is possible.
Oberon, Modula-2, Modula-3 and Pascal have all shown that it is not
at all unreasonable in terms of speed to carry out checking at this
level all the time, every time, and the overhead will be more than
swamped in the byte code interpreter. We've already _got_ fast,
unsafe languages. Don't let's let java slide into that quagmire.
If I want fast and unsafe I'll program in C++, thanks. I don't need
yet another language for that.
regards,
Larry Smith
-
This message was sent to the java-interest mailing list
Info: send 'help' to java-interest-request@java.sun.com
