[3201] in java-interest
Re: java-interest-digest V1 #244
daemon@ATHENA.MIT.EDU (Thomas Ball)
Thu Nov 2 21:51:10 1995
Date: Thu, 2 Nov 1995 15:23:09 -0800
From: Thomas.Ball@Eng.Sun.COM (Thomas Ball)
To: larrys@zk3.dec.com
Cc: java-interest@java.Eng.Sun.COM
> 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.
Someone shot your dog, Larry? You seem to be really upset, and it
doesn't seem very related to what I wrote about.
> 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.
Neither the compiler nor the runtime hides error conditions, there's
just a class of exceptions you have to either catch or promote to avoid
a compiler warning, and a class you can ignore if you don't mind them
closing your application. Any and all exceptions can be caught and
dealt with, so there is nothing to prevent your app from saying it ran
out of memory. It's your call as a Java developer how your code
handles exceptions, and whether you wish to write code without compiler
warnings.
> 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_.
So write your app to do so -- the Java runtime isn't stopping you.
> 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.
Maybe I've been lucky, but since NullPointerExceptions turn up on the
first dereference, it's been easy to determine what happened. How does
the runtime test before that dereference, when a null is a valid object
value? That test is specific to the method it's in.
Tom Ball
Java Products Group
-
This message was sent to the java-interest mailing list
Info: send 'help' to java-interest-request@java.sun.com
