From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Sun, 11 Jun 2006 18:03:20 -0700
From: Roman Shaposhnik <rvs@sun.com>
Subject: Re: [9fans] quantity vs. quality
In-reply-to: <448B5229.8050008@lanl.gov>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Message-id: <1150074200.11911.32.camel@linux.site>
MIME-version: 1.0
Content-type: text/plain
Content-transfer-encoding: 7BIT
References: <20060610015739.GA21966@ionkov.net>
	<59f06232334eddd74b8f1c78efe5621b@quanstro.net>
	<20060610001024.GB2291@submarine> <20060610023116.GB22180@ionkov.net>
	<20060610004529.GD2291@submarine> <448B5229.8050008@lanl.gov>
Topicbox-Message-UUID: 694031c8-ead1-11e9-9d60-3106f5b1d025

On Sat, 2006-06-10 at 17:13 -0600, Ronald G Minnich wrote:
> A fork fails.
> 
> Which would you rather have the kernel do: panic? Lock up (as in the old 
> days)? Or handle it gracefully.

I think that the original point (which was to demonstrate that
error handling in libraries is not just a gross oversight that
obviously conflicts with a claim of Plan9 code being clean and
otherwise superior to the average source code out there) has
been clearly demonstrated by the sheer length of the discussion
that followed. That was my goal in this discussion.

Now, I think that personally I somewhat overstated my case. Clearly,
the real question is not to chose between the death and recovery,
but rather how to develop a comprehensive strategy based on these
two. 

Being a compiler guy the most common case of error handling I see
is, of course, an invalid input given to the translator. Something
that clearly requires a recovery strategy. Yet, I'm always frustrated
at an endless stream of induced error messages when I see one. Something
that makes the code for dealing with correct recovery in C++ grow longer
every day. Longer and untested :-(

Exceptions/return values/waserror() these are all just mechanisms for
controlling the flow of your application -- they can get you to a
particular place in your code, but deciding what to do once you're
there is when it gets complicated.  

Thanks,
Roman.

P.S. It is also interesting to note that a chapter on error and
resource handling in "Practice of Programming" is the least prescriptive
of them all, basically stating that authors don't have a clear
answer.