Christopher Smith wrote:
Um, well, sure you do. If I get a division by zero error, I'm pretty
sure my introspection is still going to work.
Not at all. You have two choices with division by zero errors: either
you have a logical problem in your code (in which case you have a
logical error in your code, a.k.a. a bug, and dumping core is a very
good way to help you understand the problem) or somehow memory has
become corrupted (in which case you have an unexpected error). In the
latter case you can't trust that introspection works.
Right. Note that I'm talking about SAFE LANGUAGES. :-) The last
sentence there is exactly why I dislike unsafe languages.
And that there's a logical error in the code doesn't mean it's expected.
If I expected to be dividing by zero, I'd have put the check in in the
first place, and it would be an expected error.
And no, dumping core is entirely inappropriate in many circumstances.
It's the cause of all kinds of messiness in a lot of system services
that wind up having to fork off children just in case some piece of code
dumps core.
If I get a syntax error, or a null pointer exception, I'm also pretty
sure my introspection will still work. If you try to open a file that
doesn't exist, and you forgot to handle that failure, I'm pretty sure
your introspection will still work.
Okay, we are working across a semantic divide here. If a file doesn't
exist, that really should be an expected error.
Yes. Except I didn't check properly for the result. Hence, I didn't
expect that error, see? Hey, I figured you'd have installed the DLL at
the same time as the executable, and that nobody would make the
configuration file unreadable, and that you wouldn't pop out the USB
keyfrob while I had files open on it.
Now, of course, there can be bugs in the implementation of any
language, or hardware failures you can't detect. But we're talking
languages here.
I guess I could see where this would be a meaningful point if my
programming wasn't stuck with dealing with reality.
It's like security. It's a matter of degree. Using a safe language to
start with eliminates whole swaths of problems. It doesn't eliminate
them all.
> No matter how much I
chant that Java is a "safe" language, it proves to be painfully
difficult to work around leaks in java.util.Vector, memory corruption in
the AWT, little buffer overruns in a native JDBC driver, or my personal
favourite: JVM's that crash when they encounter byte codes that they
determine can never be reached.
And how is this worse than similar problems in an unsafe language? How
do you work around buffer overruns in any other language's system libraries?
Note that buffer overruns in native JDBC libraries are caused by using
an unsafe language, ya know. Probably the same is true of the problems
in java.util.Vector and in AWT. Had all these things actually been
written in Java, you'd not be seeing those problems. The last one is an
implementation fault (and probably an intentional one for
speed-over-correctness reasons), which you should fix at the compiler level.
Hehe. Yeah, I remember reading that Java had no undefined behavior when
I first learned the language.
"It is up to each collection to determine its own synchronization
policy. In the absence of a stronger guarantee by the implementation,
undefined behavior may result from the invocation of any method on a
collection that is being mutated by another thread; this includes direct
invocations, passing the collection to a method that might perform
invocations, and using an existing iterator to examine the collection."
Yes? So? That's not saying the language has undefined behavior. It's
saying you don't know how the implementation is written.
"When width is less than zero, Rectangle behavior is undefined.
Again, this isn't undefined behavior in Java. This is "we're not
restricting how people implement Rectangle" undefined behavior. I.e.,
this isn't "Rectangle may branch into the middle of your video memory"
undefined behavior. The insides of Rectangle still have to follow the
rules of the Java language (assuming Rectangle is implemented in Java).
Sadly, few languages actually define the difference. Ada is one of them.
--
Darren New / San Diego, CA, USA (PST)
His kernel fu is strong.
He studied at the Shao Linux Temple.
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
