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. Basically, nothing about the process'
state is certain or trustworthy. It is not unusual for attempts to
recover from an unexpected error (even with the system I've described,
but at least it gives you a decent shot at a quick recovery) to fail to
work correctly, and even make a bad situation worse.
and it is easier to code things so that process death gets things
back to a known good (or more accurately: probably good) state.
There's nothing that keeps you from cleanly exiting a failed process
in a safe language, so I think this is trivial to prove false.
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. If instead you meant some language that requires
redundant hardware, meticulously and constantly checks and corrects for
memory corruption, processor faults, hardware failures, etc. then I
guess you'd be right. I've yet to see such a language.
Oh gods this is so not true.... In particular, "safer" languages tend
to be a PITA to deal with when it comes to correcting bugs in the
language's implementation.
Uhhhh, huh? Why is it harder to correct (say) a bug in Tcl than a bug
in GCC? I've even done the former.
Sorry, I wasn't very clear with what I said. I meant more that it was
trickier to work around the problems. If you go in and actually correct
the implementation there really isn't necessarily any difference between
the two.
--Chris
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
