On Tue, Oct 28, 2003 at 02:09:10PM -0500, David Boyes wrote: | This is programmer error -- the hardware is doing exactly what it should do, | methinks. Correcting the developers usually helps, although that's much | harder. I've yet to find a programming language or toolset that doesn't do | exactly what the programmer tells it to do, even if it's stupid...8-)
OTOH, there are programming environments that change the behaviour, for better or for worse. What to do when you have an array of 100 elements numbered 0 to 99 and the code attempts to access element number 100? I've seen languages that define it to be modulo the size, so it's an access to element 0. That might be cute, but could be worse than an abrupt abort. The ability to isolate things so that aborting something doesn't put the rest at risk is the way to go about it. In Linux (or Unix) this is the process. Consider a pre-forking daemon and code that under certain conditions will crash. Let the process die and the master process can recover by logging the situation and starting a new process to keep the service level up. BTW, this is one of the reasons I avoid threads; there is the risk of cross-task damage. -- ----------------------------------------------------------------------------- | Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ | | (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ | -----------------------------------------------------------------------------
