Darren New wrote:
Christopher Smith wrote:
Darren New wrote:
ensures all the right resources are cleaned up
With a sufficiently introspective language, it's easy to get
everything cleaned up.
I'd agree with you were it an *expected* error, but for unexpected
errors, this is not the case. By definition, you don't know what the
problem is, nor what the impact is, so you can't trust that say
introspection works correctly.
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.
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.
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. 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.
I guess it depends on what you mean by a "safe" language. I presumed
you meant a language that provides some degree of correctness
checking of your source code.
Ah. No. You don't know what a "safe" language is. It actually has
nothing to do with the correctness of your source code.
"Safe" is a technical term (in the same sense that "strongly typed" is
a different technical term) that means all executions of strings that
match the language definition are well-defined. C et al is "unsafe"
because there are operation (like running off an array) that cause
undefined behavior. Java is "safe" because everything you do has a
well-defined behavior.
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."
"When width is less than zero, Rectangle behavior is undefined.
The behavior of the following methods is undefined when either width or
height is less than zero: |add()|, |contains()|, |getBounds()|,
|getSize()|, |grow()|, |inside()|, |intersection()|, |intersects()|,
|reshape()|, |resize()|, |setBounds()|, |setSize()|, |translate()|, and
|union()|."
Then there is the whole mess with double checked locking...
--Chris
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
