lsr@Apple.COM (Larry Rosenstein) (02/08/90)
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