Path: utzoo!attcan!uunet!munnari.oz.au!uhccux!ames!think!snorkelwacker!tut.cis.ohio-state.edu!bgsuvax!denbeste
From: denbeste@bgsuvax.UUCP (William C. DenBesten)
Newsgroups: comp.sys.mac
Subject: Re: Some Human Interface (was: System Error = 03)
Message-ID: <5415@bgsuvax.UUCP>
Date: 8 Feb 90 20:54:50 GMT
References: <33777@news.Think.COM>
Organization: Bowling Green State University B.G., Oh.
Lines: 59

In article <886@gistdev.gist.com> joe@gistdev.gist.com (Joe Brownlee) writes:
> The Mac interface has many features which make it superior to others, but
> when it comes to its error handling, I just don't think ID=03 is acceptable.

From article <33777@news.Think.COM>, by barmar@think.com (Barry Margolin):
>                 The translations of these bomb id's are things like
> "Segment Loader Error".  In general, the textual translation would be no
> more meaningful to the user than the numeric one.  And so what if the user
> knows what the error is?  There's still nothing he or she can do about it;
> it's a bug in the program or OS.

I think that the average user would find it helpful if the follwing
ones (for example) were reported textually.

	Memory Corupted  	id=28	DSStkNHeapHeap
	Memory Full	 	id=25	DSMemFullErr
	Application Damaged	id=16	DSBadLaunch
	Application Damaged	id=15	DSLoadErr

The average user has little use, however, for the difference between
an address error, bus error and illegal instruction (ids 1-3).
Multiple ids could be mapped to the same message.  Of course you would
still want to display the id so that those that cared about the
distinction still had the information available.



As a seperate issue, I would also like to see a trap that programmers
could call after any trap that would check all the appropiate return
codes and display an alert if the trap returned an error.

I end up writing the equivalant of a subset of this trap every time I
write a program.  I use it when a trap returns an unexpected error.
Telling the user about the error is all I can do at this point.  I use
two parameters for this sort of call. The first is a text message that
says where I am and the second is the error number.

My dream ReportError() has a textual message with limited scope and a way
to tell the computer what to do.  The choices would be:
	Ignore		- return from the trap, ignoring the error,
	Quit Application- call ExitToShell(),
	Attempt Recovery- call the ResumeProc if the application set it.
Retry would be nice but not possible since you have no way of knowing
what was just done.

As an example, the file manager's text could be limited to choosing
one of the following:
	Disk is full,
	Disk is damaged
	Can't open file,
	Can't read file,
	Can't write file,
	File Manager Error.

Limiting it this much would probably mean 50 distinct messages, which
would occupy probably 1K.  Just listing the problem would probably be
the usual case.

-- 
William C. DenBesten   is   denbeste@bgsu.edu  or   denbesten@bgsuopie.bitnet