lsr@apple.UUCP (Larry Rosenstein) (07/29/86)
{}
(An aside. In case you were not aware, Apple's news software was broken
since the middle of April, which is why there have been no postings from
Apple since then. The news software is now fixed, so we can receive and
respond to news articles again.)
I thought that I would describe the error handling mechanisms that I have
put into MacApp in order to: (1) show how we are addressing the problem,
(2) give people ideas for their applications, and (3) get some feedback.
We are addressing 2 issues: (1) how to easily detect and recover from
errors and (2) how to display meaningful alerts.
For detecting errors, I have implemented a simple error handling scheme.
(People have told me it is similar to setjmp/longjmp in C, but I am not that
familiar with C to be able to compare it)
The system maintains a stack of error handlers. Any procedure can push a
new handler on the stack; the only requirement is that it pop the handler
off before exiting. If the procedure Failure is called, the system pops the
top handler off the stack, and calls it (after restoring registers, etc.)
The handler will usually do some cleanup and then call Failure itself to
propagate the error.
MacApp has a handler in the main event loop that will catch the error,
report it, and continue. An important thing to note is that since the
error is caught in the main event loop, we can unload most of the segments
at that time, and therefore can be pretty confident about not running out
of memory while reporting the error.
We make it easy to check for errors by defining procedures such as FailOSErr
(takes an OSErr and calls Failure if < 0), FailMemErr, and FailNIL. With
this mechanism you just naturally write statements like
FailOSErr(FSWrite(...)). Also, this mechanism makes your main-line code
cleaner; there are not a lot of IF err <> noErr THEN ... tests in your code.
The Failure procedure takes an error code and a 4-byte message. The message
is looked up in a table (stored in a resource) to get an operation string
(eg., 'save the document'). There is also a special case in which the
message refers to a menu command; then the operation string becomes
'complete the "xxx" command'.
The error code is looked up in 2 tables (also in resources). The first
gives a reason for the error (eg., 'the disk is locked'), and the second a
recovery (eg., 'Eject the disk and move the little tab.'). I have found
only about 7 messages that make any sense to report, but you could use the
Resource Editor to report more specific (or terse) errors.
MacApp puts all these strings together in an alert that reads 'Could not
save the document because the disk is locked. Eject the disk and move the
little tab.'
In most cases, MacApp will supply all the parts of the error message; the
programmer only has to diligently check for errors and call Failure as
needed. In some cases, you will define new operation or reason strings, but
MacApp still takes care of putting them together and displaying the alert.
This whole alert mechanism is triggered by a call to a method, so that you
can completely override it (to do your own lookups) without changing the
MacApp source code.
If you have any questions or comments let me know.
--
Larry Rosenstein
Object Specialist
Apple Computer
AppleLink: Rosenstein1
UUCP: {sun, voder, nsc, mtxinu, dual}!apple!lsr
CSNET: lsr@Apple.CSNETcjn@calmasd.CALMA.UUCP (Cheryl Nemeth) (07/31/86)
What is MacApp?