Re: status of PL/I as a viable language

[Vinzent Hoefler <ada.rocks@jlfencey.com>]

Hyman Rosen wrote:

> Vinzent Hoefler wrote:
>> ACK. But even on one single system you cannot say if a better
>> approach would be ignoring or eventually handling the error.
> 
> Pretty much by definition, no one expects these kinds
> of errors,

Well, I always expect errors. ;)

> since they represent errors in the logic of
> the code; you would just fix the logic, not add error
> handlers.

ACK. But to do that you should first know there is an error.

> So the only thing you might have is some outer catch-all
> handler which when invoked knows only that a disaster
> has happened. So what do you do? Assume a bounded software
> error and reboot, hoping the problem will go away? Assume
> hardware failure, and go to your backups? Shut down?

Such a "global failure" action highly depends on the system you are 
controlling. In the case of a nuclear plant a clean shutdown is 
probably the safest you can do, on a mobile phone simply restarting it 
could be a more appropiate decision.

I think a significant part of the embedded systems out there currently 
use the approach to restart the system by using some watchdog timers or 
catch-all handlers and they just run fine with that.

Needless to say, that such a decision might be the wrong one for the one 
particular "unthinkable" error.

> Maybe it's just that someone miscounted the number of
> letters in 'September' and has managed to overrun an
> array by one character, and if you left it alone, the
> program would keep going just fine.

Maybe it overwrote some other parameter and now will do weird and 
possibly dangerous things. As I said, you never know until it actually 
happens.

> There's no one right answer, but I'm firmly convinced
> that ignoring errors is in the set of reasonable actions.

Sometimes, yes. At least in Ada you always have the option to turn off 
all the checks if you really want to do so.

But I think, as soon as such error is detected it should be fixed.

So IMO it should be a strong requirement to either avoid the error 
completely by doing it correct the first time or detect such error at 
runtime in whatever system we are talking about. So, even in the case 
of letting the program go on after detecting such a violation, at least 
having a chance to log it and try to recover the system without a 
"real" dedicated error handler then *could* be fine.

BTW, especially in the case of buffer overruns the system will crash 
anyway most of the times, because of a corrupted stack. Detecting the 
error before it screws everything up just makes the crash look more 
clean. ;)


Vinzent.

-- 
"I own my own body, but I share"