Re: Some example code for a new crash handler

["Daniel Hauck" <xdesign hotmail com>]

You know, your idea is probably a very good one...for now.  But look where
it leads.  We (I say "we" as if I were more than a user) need to focus on
crash protection, not handling measures, in the long run.

I am not sure where Gnome's instability comes from except to quote Scotty
from one of those Star Trek movies -- "The more you overtake the plumbing,
the easier it is to stop up the drain."  Is Gnome too complex for its own
good?

Microsoft made crashing part of every-day-life.  But to put things into
perspective, I am reminded of a job interview I had from many years ago
(back in the Windows 3.1 days).  The interviewer was from the mainframe
world and I was not.  I was interviewing for PC support.  I was asked "what
procedures would you follow under [these circumstances]..?"  Part of my
answer involved "reboot."  He cringed very noticeably.  Fortunately, my
immediate supervisor-to-be, patched the moment explaining the differences
between PC and mainframe situations to both of us. :)  I got the job, but
what an enlightening moment!

The fact still remains that programs are not supposed to "crash."  We should
write software that doesn't crash.  Instead of writing enough code to handle
all probable situations and even a lot of improbable ones, we write a
boat-load of black-box objects that we "assume" will behave correctly with
others peoples' code and in turn use other peoples' black-boxes assuming
they will do what we expect.

Okay, so some aspects of modular and object oriented programming are
irresistable and they work most of the time, but I can't help but observe
that with increased adoption of these methods of program development, we
have an increase in general instability and unpredictability coupled with
enormous "bloat" without significant improvements in overall functionality.
I see this as no different from the casual observation once made back in the
80's about the situation of the modern housewife.  (Doesn't really apply
much these days does it...)  But the observation was that asside from a few
inventions like the washing machine, all the mechanized "time saving"
inventions that have come to light and acceptance hasn't really done
anything in the end to save time and effort at all!  The remaining
housewives STILL work as much as they ever did and as hard as they ever did.
They just do it with different tools and hardly a bit more efficiently than
they did 20 to 30 years prior.

Fix the problem, don't cover it.  That's my message.  I hope it could
propogate as a new programming philosophy, but I don't carry the weight
needed to get such a message to be listened to in a broad scale.  The
plumbing has been overtaken too much and now problems are hard enough to
track down that people are taking measures to simply clean up the mess AFTER
the failure instead.

I can't deny the need for this measure because of its over-all impact on
functionality, but remember what brought us to this point in the first
place.