Xref: utzoo comp.lang.misc:5451 comp.unix.internals:45
Newsgroups: comp.lang.misc,comp.unix.internals
Path: utzoo!telly!lethe!geac!nixtdc!doug
From: doug@nixtdc.uucp (Doug Moen)
Subject: Unix error handling
Message-ID: <1990Sep2.050854.12008@nixtdc.uucp>
Reply-To: doug@nixtdc.UUCP (Doug Moen)
Organization: Nixdorf Computer Engineering Company
References: <861@dg.dg.com> <12023:Aug3017:24:1590@kramden.acf.nyu.edu> <1990Aug31.190751.12522@dg-rtp.dg.com> <556:Aug3122:09:3290@kramden.acf.nyu.edu>
Distribution: usa
Date: Sun, 2 Sep 90 05:08:54 GMT

>eliot@dg-rtp.dg.com writes:
>> But consider the reading case.
>  [ what happens upon failure? ]

brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>As Peter pointed out, this case is fatal. How many disk errors have you
>had over the last year? How many did the programs involved recover from?
>Yeah, thought so.

Sorry, but this is unacceptable.  If I am using a text editor, and
try to write out a file, and the write fails due to an I/O error,
then any decent editor will simply report the error, and return to
command mode, which allows me to attempt to write the file somewhere else,
and save my work.  The operating system should not under any circumstances
kill my editor because of a file i/o error.

In fact, I will go further, and claim that the operating system should
not kill a program out of hand, no matter what sort of error occurs.
Error handling in Unix is already a joke; kernel modifications that
make it impossible to write robust programs are not going to help the
situation.

Here's the obligatory new idea:
I don't like the fact that Unix kills a process if it blows the stack
due to an infinite recursive loop.  The problem could be fixed with
the introduction of an exception handling mechanism that the kernel
knows about.  If the stack overflows, then the kernel raises an exception
within the offending process.  The exception unwinds the stack (thereby
recovering stack space) until a stack frame containing an exception
handler is found.  If no exception handler is active, then (and only then)
is the process killed.
-- 
Doug Moen
{mnetor,alias,geac,torsqnt,lsuc}!nixtdc!doug
77 Carlton #1504, Toronto, Ontario, Canada M5B 2J7