🚀 go-pugleaf

In article <886@gistdev.gist.com> joe@gistdev.gist.com (Joe Brownlee) 
writes:
> For a machine that is based on friendliness and ease of use, the the 
error
> handling capabilities of the Mac OS are dismal.  How many messages do we 

> simple text message that concisely explains the error.  Granted, text 
takes
> space, be it on disk, in ROM, or in memory, but I experience enough 
crahses
> that I would at least like to see a message in the bomb box.  And file 
I/O
> errors like "Error #-39" should not make me reach for Inside Mac (which 
at

You are absolutely right about error handling.  

I think there are 3 cases to consider.

(1) Sad Mac codes.  These are hardware errors detected at boot time.  At 
boot time it is hard enough to display an icon, much less any text.  This 
is one case where having a short explanation would be helpful. 

(2) Bomb boxes.  These in general correspond to 68000 exceptions (address 
error, bus error), or to unrecoverable system error (can't load a 
segment).  In most cases, these are serious errors and indicate that the 
program has branched off into outer (inner?) space.

As Chuq said, when this happens you can't assume that anything in the 
Toolbox is working.  One problem with reporting these messages is that 
there are few explanations that makes sense to the average user.  (Try 
explaining an address error.)  MultiFinder does eliminate the bomb box 
itself, and I think it explains some of the errors.  It might be possible 
to do a similar thing for the non-MultiFinder case.

Errors such as not being able to load a segment can be handled by 
pre-flight checking.  You need to guarantee that there's always enough 
memory available to load a needed segment.

The original Macintosh ROMs didn't do a good job in this area.  For 
example, if you ran out of RAM while creating a picture you would get a 
bomb.  I think the Mac Plus changed this so that you would end up with an 
empty picture, which the programmer could test for.  So the system has 
been getting better over time.

(3) Finally, there are what you might call foreseen errors.  The errors in 
(1) and (2) are unforseen by the programmer.  (You don't expect that your 
app will get a bus error.)  Errors returned by I/O calls, however, can be 
foreseen and should be handled by the program.

If you look at the list of error codes, you will see that there are only  
20 or so of those that can be meaningfully reported to users.  

In MacApp we implemented a framework that maps the error codes to 
intelligent error messages.  A possible error message from a MacApp 
program is:

Could not save "foo" because the file is locked.  Use the "Get Info" 
command in the Finder to unlock the file.

(You can generate this error by opening a document under MultiFinder, then 
locking the file, making a change, and trying to save.  It's interesting 
to try this with you favorite applications -- on a scratch document of 
course.  You get a similar message if you open a document froma floppy and 
then lock the diskette.)

Messages consists of 3 parts: (1) what operation failed, (2) why it 
failed, and (3) what the user can do about it.  (In many cases, (3) isn't 
necessary, because the reason is obvious; e.g. out of disk space.)

MacApp contains resources that map error codes to explanations of the 
errors and the recovery strings.  Internally, when an error is caught, we 
use a message ID to determine what operation failed.  These strings are 
combined together to produce the error message.

The programmer is still responsible for testing for errors, but in most 
cases she doesn't have to worry about producing the appropriate messages.  
(MacApp includes utility routines to make it easy to test for errors.)  
MacApp handles not only I/O errors but also the more obscure errors such 
as when a laser printer can't be found.  (A lot of applications give a 
terrible message in this case.)

There's not much the system can do to help in this case, except to report 
all the errors rather than punting with a system error.  In retrospect, it 
would have been better to have a built-in exception handling mechanism, 
but I don't think this could be retrofitted easily.

Larry Rosenstein, Apple Computer, Inc.
Object Specialist

Internet: lsr@Apple.com   UUCP: {nsc, sun}!apple!lsr
AppleLink: Rosenstein1