Message-Id: <9211032308.AA21292@Athena.MIT.EDU>
To: sigmund@nora.hd.uib.no
Cc: jud@ithake.MIT.EDU, pbailey@ithake.MIT.EDU, harada@ithake.MIT.EDU,
        htomi@ithake.MIT.EDU, mau@ithake.MIT.EDU, lerman@Athena.MIT.EDU,
        davis@Athena.MIT.EDU, lynne@Athena.MIT.EDU, schluss@Athena.MIT.EDU,
        aybee@Athena.MIT.EDU, wjeuerle@Athena.MIT.EDU, jert@Athena.MIT.EDU,
        chess@Athena.MIT.EDU, samaa@Athena.MIT.EDU, mohcm@Athena.MIT.EDU,
        sigmund@hd.uib.no, achiqui@roman.uib.no
Subject: Re: Failing with Dignity 
Date: Tue, 03 Nov 92 18:11:22 -0500
From: Judson Harward <jud%ithake@ceci.mit.edu>

	We have not given as much thought as we should to error
recovery, and we are very open to suggestions.  It might help to
try and outline different classes of failure.  For instance,

	1 ) trying to access an unavailable resource, e.g., an extra
	8 Mb of memory, a busy videodisc player, a locked database
	2 ) error in user ADL code
	3 ) a mismatch between the application assumptions and the
	capabilities of the platform, e.g., a color application
	that wants to display 24 bit images on an 8 bit color
	system.  This is similar to ( 1 ), but maybe slightly different.

Case 1 is very system dependent.  On UNIX, when you run out of memory,
garbage collecting may help, but with abundant virtual memory, it's far more
likely that there is a gross mismatch between what you are asking the system
to do, and what it can do.  I don't know about the Mac and Windows.  In
the two other cases in (1), retrying makes much more sense.  In case 3,
there is no point in retrying, but we might well want to try to deliver
a reduced application matched to the system's capabilities.

Could you give us some more idea of how MacApp looks at it?

I'm off to vote now in the dark and rain.  Take care.

						Jud