Darren New wrote:
Christopher Smith wrote:
If you are talking about programming errors, then recovery is the
wrong kind of behavior. At most you want the code to checkpoint and
then core dump, preferably in some suitably annoying way that causes
someone to notice.
By the way, that *is* the kind of recovery I'm talking about. It's
exactly that kind of recovery that C++ and other unsafe languages
prevent. Why do you think this isn't recovery? You're not Zen enough
about your programming environment. You need to learn some languages
where the distinction between "operating system" and "application" is
as blurred as the distinction between "process" and "thread" is becoming.
Trust me. I'm a Smalltalk developer. I grok the Zen, and C++ doesn't
prevent recovery any more Java.
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.
This reminds me of James Gosling's disingenuous critique of C# when it
first came out. He pointed out that in C# you didn't have the safe
sandbox that Java provides, because the language allows you to do unsafe
operations with the "unsafe" keyword. In reality, Java has the moral
equivalent of the "unsafe" keyword in the form of Java's "native"
keyword. The only difference is that Java's "native" keyword requires
that you provide a C-based implementation (or at least interface) to the
unsafe code, while C# provides a specification for what happens in an
unsafe context. If anything I'd say the latter will tend to result in
less error prone code.
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.
I checkpoint (which requires introspection), dump core (except that I
just print a stack trace and send it to the database and/or mail it to
the support group) and then restart.
So, you produce less information about your state, and you require that
your unexpected error hasn't also screwed up your database and/or mail
access, right?
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! ;-)
--Chris
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
