Christopher Smith wrote:
Trust me. I'm a Smalltalk developer. I grok the Zen, and C++ doesn't
prevent recovery any more Java.
Cool. So, like, how does C++ recover from a random pointer being invoked
as an object with a message call, after you've already freed that
memory? Assuming it doesn't dump core, that is?
Here's the thing: you invariably are using some code that wasn't
necessarily written in a "safe" way. Whether you are using a language
that is "safe" or C++, it is possible to work at a level of abstraction
such that your application code isn't doing "unsafe" operations. Whether
you have to cross some language boundary or not to do "unsafe" work is
kind of irrelevant.
Well, obviously, the degree of "safe" depends on the definition of what
you're looking at, and from what side. Many machine languages are
"safe". Some have undefined opcodes. C is unsafe, but can be used to
implement safe languages.
I'd like to be able to look at a piece of code and say "I understand
what this does in isolation", without having to look at every other line
of code running in the entire process to know that.
Sure, in practice, the kernel is there, and the language runtime is
there, and all that. But all those things are much more developed than
my code, so if I stick with putting *my* code in the safe language, my
applications are going to be more robust. If I insist on using unsafe
languages to code, it's going to take me much longer to build robust
code, so it'll be less featureful.
If the programming error of "whoops, forgot to limit the input to the
size of my buffer" would checkpoint and dump core, we wouldn't have
zillions of viri floating around out there.
Yes, this is kind of exactly my point.
Uh huh. And I guess you're missing mine.
So, you produce less information about your state,
Yes. It only shows me what I need to know to debug it. I'd be quite
capable of dumping out as much information as your core dump provides,
if I actually ever found the need. (And sometimes I do, like when
debugging web scripts.)
and you require that
your unexpected error hasn't also screwed up your database and/or mail
access, right?
Nope. But if it hasn't (and it almost never does), then I get better
information.
Usually I don't have to restart the process, but if I can tell what
the error was, I may or may not need to. Chances are that a "socket
already in use" error isn't going to get cleared up by me restarting
the server.
Hey, that sounds like an expected error again! ;-)
Now you're cooking with gas. Safe languages are those that turn
unexpected errors into expected errors. See above null pointer comment.
--
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
