TweetFollow Us on Twitter

August 92 - LIVING IN AN EXCEPTIONAL WORLD

LIVING IN AN EXCEPTIONAL WORLD

SEAN PARENT

[IMAGE Parent_final_rev1.GIF]

Handling exceptions is a difficult but important part of developing Macintosh applications. This article provides a methodology as well as a set of C tools for handling exceptions and writing robust code. Techniques and examples are provided for dealing with some of the Toolbox idiosyncrasies, and some interesting features of the C preprocessor, MacsBug, and MPW are explored.


Writing software on the Macintosh can be difficult. Writing robust software on the Macintosh is even more difficult. Every call to the Toolbox is a potential source of a bug and there are too many cases to handle--what if there isn't enough memory, or the disk containing the code has been ejected, or there isn't enough stack space, or the printer is unplugged, or . . . The list goes on, and a well-written application is expected to handle every case--always recovering without loss of information. By looking at how software is developed, this article introduces a methodology and tools for handling the exceptional cases with minimal impact on the code that handles the task at hand.

VERSION 1: NORMAL FLOW OF CONTROL

When writing code, programmers usually begin by writing the normal flow of control--no error handling. The code shown below is a reconstruction of the first version of a printing loop routine that eventually went out as a Macintosh Technical Note, "A Printing Loop That Cares . . ." (#161). Note that comments were removed to make the structure more apparent.

#include <Printing.h>
#include <Resources.h>
#include <Memory.h>

void PrintStuff(void)
{
    GrafPtr         oldPort;
    short           copies, firstPage, lastPage, numCopies,
                    printmgrsResFile, realNumberOfPagesInDoc,
                    pageNumber;
    DialogPtr       printingStatusDialog;
    THPrint         thePrRecHdl;
    TPPrPort        thePrPort;
    TPrStatus       theStatus;

    GetPort(&oldPort);
    UnLoadTheWorld();
    thePrRecHdl = (THPrint)NewHandle(sizeof(TPrint));
    PrOpen();
    printmgrsResFile = CurResFile();
    PrintDefault(thePrRecHdl);
    if (PrStlDialog(thePrRecHdl)) {
        realNumberOfPagesInDoc = DetermineNumberOfPagesInDoc(
            (**thePrRecHdl).prInfo.rPage);
        if (PrJobDialog(thePrRecHdl)) {
            numCopies = (**thePrRecHdl).prJob.iCopies;
            firstPage = (**thePrRecHdl).prJob.iFstPage;
            lastPage = (**thePrRecHdl).prJob.iLstPage;
            (**thePrRecHdl).prJob.iFstPage = 1;
            (**thePrRecHdl).prJob.iLstPage = 9999;
            if (realNumberOfPagesInDoc < lastPage) {
                lastPage = realNumberOfPagesInDoc;
            }
            printingStatusDialog =
                GetNewDialog(257, nil, (WindowPtr) -1);
            for (copies = 1; copies <= numCopies; copies++) {
                (**thePrRecHdl).prJob.pIdleProc =
                    CheckMyPrintDialogButton;
                UseResFile(printmgrsResFile);
                thePrPort = PrOpenDoc(thePrRecHdl, nil, nil);
                pageNumber = firstPage;
                while (pageNumber <= lastPage) {
                    PrOpenPage(thePrPort, nil);
                    DrawStuff((**thePrRecHdl).prInfo.rPage,
                        (GrafPtr)thePrPort, pageNumber);
                    PrClosePage(thePrPort);
                    ++pageNumber;
                }
                PrCloseDoc(thePrPort);
            }
            if ((**thePrRecHdl).prJob.bJDocLoop == bSpoolLoop) {
                PrPicFile(thePrRecHdl, nil, nil, nil, &theStatus);
            }
        }
    }
    PrClose();
    DisposeHandle((Handle)thePrRecHdl);
    DisposeDialog(printingStatusDialog);
    SetPort(oldPort);
} /* PrintStuff */ 

VERSION 2: ERROR HANDLING ADDED

With code in the preliminary stage shown above, the flow of control is easy to follow. After writing it, the programmer probably read through it and added some error-handling code. Adding "if (error == noErr)" logic wasn't difficult, but it took some thought to determine how to handle the cleanup and deal with the two loops. Some more error-handling code may have been added after running the routine under stressful conditions. Perhaps it was reviewed by lots of people before it went out as a Technical Note. Here's the new version of the code (with the added error-handling code shown in bold):

#include <Printing.h>
#include <Resources.h>
#include <Memory.h>

void PrintStuff(void)
{
    GrafPtr         oldPort;
    short           copies, firstPage, lastPage, numCopies,
                    printmgrsResFile, realNumberOfPagesInDoc,
                    pageNumber, printError;
    DialogPtr       printingStatusDialog;
    THPrint         thePrRecHdl;
    TPPrPort        thePrPort;
    TPrStatus       theStatus;

    GetPort(&oldPort);
    UnLoadTheWorld();
    thePrRecHdl = (THPrint)NewHandle(sizeof(TPrint));
    if (MemError() == noErr && thePrRecHdl != nil) {
        PrOpen();
        if (PrError() == noErr) {
            printmgrsResFile = CurResFile();
            PrintDefault(thePrRecHdl);
            if (PrError() == noErr) {
                if (PrStlDialog(thePrRecHdl)) {
                    realNumberOfPagesInDoc =
                        DetermineNumberOfPagesInDoc(
                        (**thePrRecHdl).prInfo.rPage);
                    if (PrJobDialog(thePrRecHdl)) {
                        numCopies = (**thePrRecHdl).prJob.iCopies;
                        firstPage = (**thePrRecHdl).prJob.iFstPage;
                        lastPage = (**thePrRecHdl).prJob.iLstPage;
                        (**thePrRecHdl).prJob.iFstPage = 1;
                        (**thePrRecHdl).prJob.iLstPage = 9999;
                        if (realNumberOfPagesInDoc < lastPage) {
                            lastPage = realNumberOfPagesInDoc;
                        }
                        printingStatusDialog =
                            GetNewDialog(257, nil, (WindowPtr) -1);
                        for (copies = 1; copies <= numCopies;
                             copies++) {
                            (**thePrRecHdl).prJob.pIdleProc =
                                CheckMyPrintDialogButton;
                            UseResFile(printmgrsResFile);
                            thePrPort =
                                PrOpenDoc(thePrRecHdl, nil, nil);
                            if (PrError() == noErr) {
                                pageNumber = firstPage;
                                while (pageNumber <= lastPage &&
                                        PrError() == noErr) {
                                    PrOpenPage(thePrPort, nil);
                                    if (PrError() == noErr) {
                                        DrawStuff(
                                            (**thePrRecHdl).prInfo.
                                                rPage,
                                            (GrafPtr)thePrPort,
                                            pageNumber);
                                    }
                                    PrClosePage(thePrPort);
                                    ++pageNumber;
                                }
                            }
                            PrCloseDoc(thePrPort);
                        }
                    } else PrSetError(iPrAbort);
                } else PrSetError(iPrAbort);
            }
        }
        if (((**thePrRecHdl).prJob.bJDocLoop == bSpoolLoop) &&
                (PrError() == noErr)) {
            PrPicFile(thePrRecHdl, nil, nil, nil, &theStatus);
        }
        printError = PrError();
        PrClose();
        if (printError != noErr)
            PostPrintingErrors(printError);
    }
    if (thePrRecHdl != nil)  DisposeHandle((Handle)thePrRecHdl);
    if (printingStatusDialog != nil)
        DisposeDialog(printingStatusDialog);
    SetPort(oldPort);
} /* PrintStuff */

Can you easily follow the normal flow of control in the second version? What if an error occurs? Could an error ever go unreported? Could this code crash because it didn't handle an error? Does this routine always clean up after itself? These questions are difficult to answer because the normal flow of control of this routine is intertwined with the flow that will occur in the event of an error. If the two could be separated, it would be much easier to tell what the routine does normally and how things are handled when something goes wrong. Besides making the code easier to read, a methodology that allowed such separation would make the code easier to write, debug, and, maintain.

PROGRAMMING BY CONTRACT

Programming by contract is based on the assumption that all correct routines have a contract, either stated or implied, with their caller. The contract states that if a given set of preconditions is met, the routine either succeeds or flags an exception and leaves the machine in a known or determinable state. This contract is flexible enough to be applied to any correct code.

The secret to writing robust code is to understand what the preconditions of a given routine are, when an exception can be flagged, and how to handle the exception. Separating the logic that checks conditions and handles exceptions from the algorithm of the routine allows code to be written in a straightforward way with the flow of control seen as easily as in our first version.

PRECONDITIONS
The preconditions of a routine specify the state the machine must be in for the routine to execute without failure (where failure implies a crash--not flagging an exception). A routine may require in its precondition items such as

  • a previously called initialization routine
  • valid ranges for value parameters
  • available memory
  • initialization of global state
  • a specific software version

For some routines the preconditions may be readily apparent either in the interface or in the documentation. Sometimes it's necessary to experiment to discover the preconditions of a routine. When writing a routine, the "strength" of the precondition can be set according to the use of the routine. For example, a routine named DivideLong is written with a description that states: Given two numbers, numer and denom, DivideLong will divide numer by denom, set numer to the result, and return noErr. If denom is zero, DivideLong will return divideByZeroErr and leave numer unchanged.

With this description, numer and denom can be any numbers of the proper type. This is a weak precondition. Another description might read: Given two numbers, numer and denom, DivideLong will divide numer by denom and return the result. If denom is zero, DivideLong will fail.

With the second description, it would be the caller's responsibility to ensure that denom isn't zero. This is a strong precondition.

In general, it's better to have a strong precondition in a routine that is used within a sequence of related routines or shares conditions with other routines, because it generates more efficient code byeliminating error checking. It's better to have a weak precondition in routines that are called only once or at the start of a sequence of related routines. Routines with weak preconditions free the caller from ensuring the state of the machine before making the call.

A precondition can be strengthened by the caller but must not be weakened. Strengthening is useful when you're making a sequence of related calls where being sure additional conditions are met guarantees that no routine flags an exception. For example, given the first description of DivideLong it would be valid for a caller to do the following:

if (denom != 0) {
(void)DivideLong(&numer_a, denom); /* Ignore return. */
(void)DivideLong(&numer_b, denom); /* Ignore return. */
} else HandleError();

This may be more desirable than checking for a result of divideByZeroErr after each call. An example of weakening a precondition would be to call DivideLong as described in the second description without ensuring that denom isn't zero. This would constitute a bug.

POST-CONDITIONS
Post-conditions specify the state of the machine on the return of a routine. They include side effects and changes to global state as well as function results and variable parameters. The post-conditions of a routine must be determinable for the routine to be correct. They don't vary in strength and, if not met, the routine has a bug. A thorough understanding of the post-conditions of a routine is required to ensure that the routine is being called correctly and that cleanup can occur when the routine flags an exception.

Sometimes it's necessary to rephrase the preconditions and post-conditions of a routine to use it correctly. For example, a common misconception is that the only preconditions for calling TEKey are that it has passed a valid TEHandle and the appropriate Managers have been initialized. Since there's no mechanism for TEKey to flag an exception, the assumption is that it can't fail. But TEKey may need to grow the hText handle if the character isn't replacing others and isn't a backspace. Growing a handle requires memory--something there may not be enough of. Since TEKey can fail without flagging an exception with these preconditions, it appears to be incorrect and contain a bug. However, by strengthening the preconditions to require that hText must be able to grow by the size of a character, the routine is once again correct. Strengthening preconditions is an easy fix often used in system software. (See the section "Preflighting Calls" for tips on how to ensure preconditions.)

HOW TO WRITE CHECKS
The checkmacro is used to ensure that static preconditions and post-conditions are being met during development. It also documents conditions for you, making it a very useful tool that adds to the maintainability of the code. Unfortunately, these conditions cannot be expressed directly in the interface so as to be more apparent to the caller. The syntax forcheckis

check(assertion );

To use thecheck macro, include Exceptions.h (provided on theDeveloper CD Series disc). For MacsBug, use ResEdit to add Exceptions.rsrc to the DebuggerPrefs file in the System Folder.

What checkdoes depends on the setting of the compile-time variable DEBUGLEVEL. DEBUGLEVEL can be set to one of the following values:

  • DEBUGOFF or DEBUGWARN:checkdoes nothing andassertion is not evaluated.
  • DEBUGMIN or DEBUGSYM:assertion is evaluated and, if it's false (zero), a debugger break is executed. (The debugger break is Debugger ( ) for DEBUGMIN and SysBreak ( ) for DEBUGSYM. The first is useful for low-level debuggers like MacsBug or TMON, the second for symbolic debuggers like SourceBug, SADE, or THINK C.)
  • DEBUGON or DEBUGFULL:assertion is evaluated and, if it's false (zero), MacsBug is entered and the dprintf dcmd is invoked to display more information. If DEBUGON,assertion is displayed and if DEBUGFULL, the source code file and line number are also displayed (see "Wonders of MacsBug and dprintf" for more information about dprintf).

Normally,checkis used at the start and end of a routine. At the start it's used to ensure that parameters are within a given range and are not specific values (such as nil). At the end it's used to ensure that allocations succeeded and results are as desired.

REQUIREMENTS FOR BETTER LIVING

Althoughcheckcan ensure that preconditions and post-conditions are being met during development,checkis of limited value in situations where it cannot be determined whether the conditions are being met statically, because
  • it disappears when DEBUGLEVEL is set to DEBUGOFF
  • it doesn't provide sufficient support for handling exceptions to return the machine to a known state

What's needed is a mechanism that does not compile out and provides the ability to invoke a handler whenassertion fails.

WHAT WE REQUIRE
The requiremacro was created to make handling exceptions simpler. The syntax forrequireis

require(assertion , exception );

Ifassertion evaluates to false (zero), execution continues at the handlerexception . (Theexception parameter, by convention, shares the name of the routine that failed, but this isn't mandatory.) Handlers are typically written as shells with control falling from one to the next, cleaning up after prior calls along the way. The extent of the cleanup needed gets deeper as more of the routine succeeds. Figure 1 shows an extended form ofrequirecalled require_action. The extended form executes a statement whenassertion fails before executing the handler. This is most useful for setting an error variable. The syntax forrequire_actionis

require_action(assertion , exception , action );

Like check, requirebreaks into MacsBug and displays pertinent information depending on the settings of DEBUGLEVEL. Unlikecheck, requiredoes not compile out when DEBUGLEVEL is set to DEBUGWARN or DEBUGOFF. It evaluatesassertion and invokes the handler (andaction ), but no break occurs.

The nrequiremacro is equivalent torequire(! assertion , exception ). However, under rare circumstances it generates more efficient code, and when debugging is on, it displays the value ofassertion . It's also easier to read. As a general rule, userequirewith handles and pointers andnrequirewith errors.

VERSION 3: IMPROVED WITH REQUIRE

A close look at the code in version 2 reveals some problems:
  • No error handling is done after PrCloseDoc, though any errors will get caught either after the next PrOpenDoc or on exit.
  • If the NewHandle at the start of the code fails, it won't print and the user is never notified why.
  • If an error occurs in the copies loop, the loop isn't terminated.

If printing is well behaved and does nothing once PrError has been set, none of these problems poses much of a threat to the actual stability of the code (with the exception of GetNewDialog). However, the use ofrequirewhen writing the code could have avoided the problems and the code would be easier to understand and maintain. This is shown in the code below--version 3. The structure of the code in version 3 is almost identical to version 1 with the addition of therequirestatements and the handlers at the end. Writing code like this is straightforward. When a routine is called that can flag an exception, arequirestatement is added with a handler. The statements executed in a handler typically clean up after the routines called before the routine flagging the exception. (See the section "When To Clean Up" for more discussion.) Although PrClose should never cause an error, acheck statement was added during development.

Here's version 3 of the code (with changes from version 1 shown in bold):

#include <Printing.h>
#include <Resources.h>
#include <Memory.h>
#include <Errors.h>
#include "Exceptions.h"

void PrintStuff(void)
{
    GrafPtr     oldPort;
    short       copies, firstPage, lastPage, numCopies,
                printmgrsResFile, realNumberOfPagesInDoc,
                pageNumber;
    DialogPtr   printingStatusDialog;
    OSErr       theError;
    THPrint     thePrRecHdl;
    TPPrPort    thePrPort;
    TPrStatus   theStatus;
    long        contig, total;
    
    enum { dialogSlop = 8192 };

    GetPort(&oldPort);
    UnLoadTheWorld();
    
    thePrRecHdl = (THPrint)NewHandle(sizeof(TPrint));
    require_action(thePrRecHdl, NewHandle,
        theError = MemError(););
    
    PrOpen();
    nrequire(theError = PrError(), PrOpen);
    
    printmgrsResFile = CurResFile();
    PrintDefault(thePrRecHdl);
    nrequire(theError = PrError(), PrintDefault);
    
    if (PrStlDialog(thePrRecHdl)) {
        realNumberOfPagesInDoc = DetermineNumberOfPagesInDoc(
            (**thePrRecHdl).prInfo.rPage);
        if (PrJobDialog(thePrRecHdl)) {
            numCopies = (**thePrRecHdl).prJob.iCopies;
            firstPage = (**thePrRecHdl).prJob.iFstPage;
            lastPage = (**thePrRecHdl).prJob.iLstPage;
            (**thePrRecHdl).prJob.iFstPage = 1;
            (**thePrRecHdl).prJob.iLstPage = 9999;
            if (realNumberOfPagesInDoc < lastPage) {
                lastPage = realNumberOfPagesInDoc;
            }
            
            PurgeSpace(&total, &contig);
            require_action(contig >= dialogSlop, PurgeSpace,
                theError = memFullErr;);
            
            printingStatusDialog =
                GetNewDialog(257, nil, (WindowPtr) -1);
            require_action(printingStatusDialog, GetNewDialog,
                theError = memFullErr;);
            
            for (copies = 1; copies <= numCopies; copies++) {
                (**thePrRecHdl).prJob.pIdleProc =
                    CheckMyPrintDialogButton;
                UseResFile(printmgrsResFile);
                thePrPort = PrOpenDoc(thePrRecHdl, nil, nil);
                nrequire(theError = PrError(), PrOpenDoc);
                
                pageNumber = firstPage;
                while (pageNumber <= lastPage) {
                    PrOpenPage(thePrPort, nil);
                    nrequire(theError = PrError(), PrOpenPage);
                    
                    DrawStuff((**thePrRecHdl).prInfo.rPage,
                        (GrafPtr)thePrPort, pageNumber);
                    PrClosePage(thePrPort);
                    nrequire(theError = PrError(),
                        PrClosePage);
                    
                    ++pageNumber;
                }
                PrCloseDoc(thePrPort);
                nrequire(theError = PrError(), PrCloseDoc);
            }
            if ((**thePrRecHdl).prJob.bJDocLoop == bSpoolLoop) {
                PrPicFile(thePrRecHdl, nil, nil, nil, &theStatus);
                nrequire(theError = PrError(), PrPicFile);
            }
        }
    }

    PrClose();
    ncheck(PrError());
    
    DisposeHandle((Handle)thePrRecHdl);
    DisposeDialog(printingStatusDialog);
    SetPort(oldPort);
    return;

PrOpenPage:
    PrClosePage(thePrPort);
PrClosePage:
PrOpenDoc:
    PrCloseDoc(thePrPort);
PrPicFile:
PrCloseDoc:
    DisposeDialog(printingStatusDialog);
GetNewDialog:
PurgeSpace:
PrintDefault:
PrOpen:
    PrClose();
    DisposeHandle((Handle)thePrRecHdl);
NewHandle:
    SetPort(oldPort);
    PostPrintingErrors(theError);
} /* PrintStuff */

PREFLIGHTING CALLS

Preflighting a call is the process of ensuring that the preconditions are met. Usually this isn't necessary since the preconditions will be satisfied by handling the exceptions of prior calls or will be implicit in the caller's preconditions. For example, there's no need to ensure that the TEHandle being passed to TEKey isn't nil if the exceptional case of the previous TENew returning nil was handled. In case preconditions haven't been satisfied by handling the exceptions of previous calls,requirecan be used to check the precondition and invoke a handler if it's not being met. This is especially useful for routines that have strong preconditions or preconditions that are difficult to determine. Earlier, TEKey was used as an example of a routine with strong preconditions. To ensure the preconditions for TEKey,requirecould be used as follows:

OSErr SafeTEKey(short key, TEHandle hTE) {
    enum { teSlop = 1024 };

    OSErr       error;
    TEPtr       w               = *hTE;
    Handle      hText           = w->hText;
    short       teLength        = w->teLength;
    
    SetHandleSize(hText, teLength + teSlop);
    nrequire(error = MemError(), SetHandleSize);
    SetHandleSize(hText, teLength);
    TEKey(key, hTE);
    return(noErr);
    
SetHandleSize:
    return error;
}

The constant teSlop is used instead of 1 just to be safe. Adding some slop for routines with implied, rather than stated, preconditions is always a good idea.

For some routines the preconditions are too complex or subject to change to accurately state as an assertion. This is the case for GetNewDialog, as shown in version 3. GetNewDialog can fail when there isn't enough memory for one of the numerous QuickDraw elements to be allocated, to load the WDEF, or, if the dialog contains TextEdit items, to create the TEHandle. About all that can be done to guarantee that GetNewDialog succeeds is to ensure that there's a reasonable amount of memory available. It's fairly safe to rely on the Process Manager in System 7 to make sure there's space in the system heap for the WDEF. This is what's done in version 3. The assertion is based on contiguous memory instead of total memory in case the heap is too fragmented to allocate some of the larger blocks required. Sometimes all that can be done is to increase the chances of survival.

WHEN TO CLEAN UP

Just as preconditions can sometimes be tricky to determine, post-conditions can be hazardous as well. It's important to understand the post-conditions of the routines being called, so that the machine can be returned to a known state, ensuring valid post-conditions for the calling routine. Normally, if an exception is being raised, a routine should dispose of everything itsuccessfully allocated, close everything itsuccessfully opened, and release everything itsuccessfully locked. So, if NewHandle is called successfully, DisposeHandle is called in the handler. If OpenFile is called successfully, CloseFile is called in the handler.

But this rule isn't always true. One counterexample is the Printing Manager. Even if PrOpen flags an exception PrClosemust  be called. The same is true for PrOpenDocument and PrOpenPage.

Shared resources present another potential problem. If GetResource is successfully called on a system resource, it's a bad idea to release it, because it may also be in use by another routine. SetResLoad(false) and GetResource can be called to determine whether the resource is already in memory before loading it, and then it can be released only if it was loaded. This, however, is taking things to an extreme. It may be better to document that these resources may be loaded even if the routine flags an exception. Since this is determinable by the caller, it suffices as a valid post- condition.

FUTURE DIRECTIONS

The routines and macros provided in Exceptions.h lay the foundation for writing robust software. There are more sophisticated exception-handling mechanisms, such as the proposedcatch andthrow implementation for C++. Ada has a reasonable exception-handling mechanism, as does CLU and Eiffel. However, these mechanisms don't lend themselves to dealing with exceptions from routines that were not written using the same mechanism and so are difficult to use on the Macintosh when dealing with the OS and Toolbox. Thecheckand requiremacros are flexible enough to be useful in most situations and are implemented in C, so they can be of value for many (if not most) existing projects. They are also C++ friendly and can be of great use to C++ programmers as well.

After you read the code in version 3 that uses these macros it should be fairly simple to answer the questions asked about version 2 at the beginning of the article. This is left as an exercise.

Turn the page if you want even more detail . .

MORE DETAIL THAN MOST FOLKS NEED

The require and check macro implementation is shown in Figure 2. To ensure that there aren't any side effects, any macro that's larger than a single statement is enclosed in do { } while(false). This ensures that the macro behaves as a simple statement and can be used anyplace a simple statement would be (such as after an if). The do { } while(false) does not generate any object code. In some of the macros, if statements appear in the form

if (assertion) ; /* Do nothing. */
else { /* Do something. */ }

Under some conditions, this will generate more efficient code than

if (!assertion) { /* Do something. */ }

(This was especially true back in the days of the MPW 3.1 compiler.) There are variables declared within the scope of the macros when debugging is on. This avoids side effects caused by evaluating assertion  multiple times (once in the condition and once to display it). For example:

nrequire(ReadCharacters(), Fail);

If ReadCharacters returned a value other than nil, MacsBug would be invoked to display the result before executing the handler Fail. Without the local variable, ReadCharacters would be executed a second time to display the value. The second execution may cause side effects like increasing a file pointer as well as reading in a different set of characters.

When assertion  is an error code returned by a function, it can be assigned to a variable to preserve the error. This also keeps the exception-handling code enclosed within the requirestatement. For example:

nrequire(error = GetError(), Fail);

However, with warnings set to full, this invokes a warning because the assignment takes place as part of anif statement. Using

error = GetError();
nrequire(error, Fail);

generates identical code (at least with MPW 3.2) and doesn't cause any warnings.

A macro, resume, is provided for recovering from exceptions. It's used within a handler and takes the form

resume(exception );

where exception  corresponds to exception  used in a require statement. The resume macro simply transfers control to the point immediately following the require statement. Because of the resume feature, multiplerequire statements cannot share the same exception handler. Sometimes sharing a handler is convenient, soresume can be disabled with a statement:

#define resumeLabel(exception)

To reenable resume, use

#define resumeLabel(exception)\ 
    resume_ ## exception:

There's also a check_actionmacro which, like require_action, allows a statement to be executed whenassertion  fails. The check_action macro compiles out like all check macros and should be viewed as a development-time tool only. Being able to execute a statement allows for the exit of a routine if the preconditions aren't met.

#define require(assertion, exception)               \
    do {                                                \
        if (assertion) ;                                \
        else {                                          \
            dprintf(notrace,                            \
                "Assertion \"%s\" Failed\n"     \
                "Exception \"%s\" Raised",          \
                #assertion, #exception);            \
            goto exception;                         \
            resumeLabel(exception);                 \
        }                                               \
    } while (false)

#define check(assertion)                            \
    do {                                                \
        if (assertion) ;                                \
        else {                                          \
            dprintf(notrace,                            \
                "Assertion \"%s\" Failed",          \
                #assertion);                            \
        }                                               \
    } while (false)


Figure 2Implementing require and check

WONDERS OF MACSBUG AND DPRINTF

The MacsBug dcmd, dprintf, is used by the requireand check macros to display useful debugging information. The dprintf command is also a powerful tool that provides all the features of the standard printf but uses MacsBug as the console. The dprintf command assumes MPW parameter-passing conventions. The syntax for dprintf is

dprintf([no]trace, formatString , ...);

where trace and notrace are used to specify whether or not to continue after displaying the information in MacsBug. The variable formatString  is a printf style- format string with some extensions (see the comment in the Exceptions.h file on the Developer CD Series  disc). Following formatString are the parameters to display. This can be a very useful tool for viewing complex structures or difficult-to-read values like floating- or fixed-point numbers.The implementation of the dprintf dcmd is shown in the DPrintf.c file on the CD. It's fairly straightforward and can be extended easily to add any special data types required (for example, a t format character that would take a pointer to text and an integer length and display the text). The dcmd is invoked from C using the inline declaration for dprintf. The inline declaration invokes the DebugStr trap and pushes a long on the stack. The push is required because DebugStr uses Pascal calling conventions and so pops the [ no]trace string from the stack. Since dprintf is a C-based function, the stack is fixed, so the string isn't popped twice. Both traceand notrace are macro Pascal strings containing ";dprintf;doTrace" and ";dprintf". Since the strings begin with a semicolon, MacsBug interprets them as commands and executes them. The dcmd then fetches the parameters from the stack according to formatString and displays them. The MacsBug macro doTraceevaluates to "g" or "". It's used to switch tracing between trace and break by entering either traceGo ortraceBreak in MacsBug.

When developing software, it's useful to insert dprintf statements to display information in sections of code that are executed only in unusual circumstances. If dprintf is bracketed with #if debugon / #endif directives, it compiles out when DEBUGLEVEL is set to DEBUGWARN or DEBUGOFF. With trace the information is displayed without seriously interrupting the execution of the code. The trace macro is also useful for logging timing statistics by displaying Ticks. Since formatString  is interpreted in MacsBug with interrupts disabled, even a complex formatString  has minimal impact on timing results.

MACSBUG POWER USER TIP
If you have more than one monitor, you can use the swap command to make MacsBug always visible and use dprintf with trace to continually log information. You can set which screen MacsBug uses by opening the Monitors control panel, holding down the Option key, and dragging the "Happy Macintosh" to the monitor on which you want to display MacsBug (you have to restart for it to take effect).

MPW POWER USER TIP
At the end of the comment for dprintf in Exceptions.h is a section that uses Echo to pipe code to the assembler.

/*********************************************
Echo "                         ðnð
 PRINT      OFF,NOHDR               ðnð
 INCLUDE    'Traps.a'               ðnð
 PRINT      ON                      ðnð
 PROC                               ðnð
 _DebugStr                          ðnð
 SUBQ       #4,SP   ; Fix the stack ðnð
 ENDPROC                            ðnð
 END                                ðnð
" | Asm -l
*********************************************/

If you select this section and press Enter, it generates a listing with hex output. This is a handy way to generate and document inline functions..

RELATED READING

  • Macintosh Technical Note "A Printing Loop That Cares . . ." (formerly #161).
  • Object-Oriented Software Construction  by Bertrand Meyer (Prentice-Hall, 1988). Contains more information on programming by contract.
  • Debugging Macintosh Software with MacsBug  by Konstantin Othmer and Jim Straus (Addison-Wesley, 1991). Contains additional MacsBug tips.

SEAN PARENT (AppleLink PARENT, Internet parent@apple.com) is  a parent, but Parent is his last name, not his title. He grew up in Renton, Washington, with his parents (you know, the people who produced him), who are also Parents. Sean came to Apple to pursue his lifelong interest in reference manuals. He enjoys a good ANSI standards document duringbreakfast, and likes catchy punch lines such as, "No, no! I said 'ANSI,' not 'ASCII'!" Sean also likes to write a good hack, and consistently comes in next-to-second-best at the annual MacHack MacHax Hack Contest. Unable to hide his prowess, he gave in to the inevitable job at Apple, and now he wants to change the world, one programming paradigm at a time.*

CouldDialog, which was intended as a preflight tool for GetNewDialog, is a no-op in System 7 (it's been broken since the Macintosh II was introduced).*

Seriously insane cycle counters take note that the MPW 3.2 C compiler doesn't reuse a register to store a variable in a local scope when the register was used in a prior scope containing a goto statement (require generates a goto). This can lead to code that isn't as efficient as it should be but can usually be coded around (it's difficult to generate in the first place). Hopefully this will be fixed in a future compiler. *

THANKS TO OUR TECHNICAL REVIEWERS Scott Boyd, Konstantin Othmer, Sam Weiss. Also, special thanks to everyone in the Print Shop (present and former members) for using this stuff and suggesting numerous improvements during the past few years. *

 
AAPL
$99.18
Apple Inc.
-1.57
MSFT
$45.90
Microsoft Corpora
-0.46
GOOG
$568.27
Google Inc.
-9.09

MacTech Search:
Community Search:

Software Updates via MacUpdate

Cocktail 8.0 Beta 2 - General maintenanc...
Cocktail is a general purpose utility for OS X that lets you clean, repair and optimize your Mac. It is a powerful digital toolset that helps hundreds of thousands of Mac users around the world get... Read more
QuickBooks 2015 16.0.0.1352 R1 - Financi...
QuickBooks 2015 helps you manage your business easily and efficiently. Organize your finances all in one place, track money going in and out of your business, and spot areas where you can save.... Read more
Mac DVDRipper Pro 5.0.1 - Copy, backup,...
Mac DVDRipper Pro is the DVD backup solution that lets you protect your DVDs from scratches, save your batteries by reading your movies from your hard disk, manage your collection with just a few... Read more
Apple OS X bash Update 1.0 - Fix for sec...
The OS X bash Update fixes a security flaw in the bash UNIX shell on OS X 10.9.5 (also on OS X 10.8 and 10.7 [see Related Links below]). OS X 10.9.5 or later Downloads for OS X 10.8 and OS X 10.7 in... Read more
SyncTwoFolders 2.0.5 - Syncs two user-sp...
SyncTwoFolders simply synchronizes two folders. It supports synchronization across mounted network drives and it is a possibility to run a simulation showing in a log what will be done. Please visit... Read more
FinderPop 2.5.7 - Classic Mac utility, n...
FinderPop is a Universal preference pane that extends OS X's contextual menus using a FinderPop Items folder much as the Apple Menu Items folder used to do for the Apple menu. It has other features... Read more
VueScan 9.4.45 - Scanner software with a...
VueScan is a scanning program that works with most high-quality flatbed and film scanners to produce scans that have excellent color fidelity and color balance. VueScan is easy to use, and has... Read more
LibreOffice 4.3.2.2 - Free Open Source o...
LibreOffice is an office suite (word processor, spreadsheet, presentations, drawing tool) compatible with other major office suites. The Document Foundation is coordinating development and... Read more
calibre 2.4 - Complete e-library managem...
Calibre is a complete e-book library manager. Organize your collection, convert your books to multiple formats, and sync with all of your devices. Let Calibre be your multi-tasking digital... Read more
Default Folder X 4.6.9b1 - Enhances Open...
Default Folder X attaches a toolbar to the right side of the Open and Save dialogs in any OS X-native application. The toolbar gives you fast access to various folders and commands. You just click... Read more

Latest Forum Discussions

See All

Manage Your Cloud – Wunderlist Now Suppo...
Manage Your Cloud – Wunderlist Now Supports Dropbox Posted by Jessica Fisher on October 1st, 2014 [ permalink ] Universal App - Designed for iPhone and iPad | Read more »
Nexticy Review
Nexticy Review By Jennifer Allen on October 1st, 2014 Our Rating: :: IDEAL FORM CREATIONiPad Only App - Designed for the iPad Nexticy allows you to make your own forms for research purposes or to organize your business better. It’s... | Read more »
Tiny Troopers: Alliance Marches onto the...
Tiny Troopers: Alliance Marches onto the App Store Tomorrow Posted by Jessica Fisher on October 1st, 2014 [ permalink ] Tiny Troopers: Alliance, by Kukouri, is a | Read more »
HeroCraft Introduces Unlimited Sequel to...
HeroCraft Introduces Unlimited Sequel to WW2: Sandbox. Strategy & Tactics Posted by Jessica Fisher on October 1st, 2014 [ permalink ] | Read more »
RGB Express Review
RGB Express Review By Jennifer Allen on October 1st, 2014 Our Rating: :: DELIGHTFUL PUZZLINGUniversal App - Designed for iPhone and iPad Guide trucks along their delivery routes in RGB Express, a testing but charming puzzle game... | Read more »
The Sagas of Fire*Wolf (Games)
The Sagas of Fire*Wolf 1.0 Device: iOS Universal Category: Games Price: $9.99, Version: 1.0 (iTunes) Description: | Read more »
BuggyFun Review
BuggyFun Review By Amy Solomon on October 1st, 2014 Our Rating: iPad Only App - Designed for the iPad BuggyFun allows children to create their own tracks for bugs to interact with for a unique open-ended experience.   | Read more »
Fold the Adventure Review
Fold the Adventure Review By Jennifer Allen on October 1st, 2014 Our Rating: :: AWKWARD FOLDSUniversal App - Designed for iPhone and iPad Fold pieces of paper to create platforms for a princely rabbit in this puzzle game; something... | Read more »
WW2: Sandbox. Strategy & Tactics (G...
WW2: Sandbox. Strategy & Tactics 1.0.0 Device: iOS Universal Category: Games Price: $9.99, Version: 1.0.0 (iTunes) Description: ***NOTE: Compatible with iPhone 4s and up, iPad 2 and up - may not work properly on earlier devices... | Read more »
apeFilter (Music)
apeFilter 1.0 Device: iOS Universal Category: Music Price: $6.99, Version: 1.0 (iTunes) Description: | Read more »

Price Scanner via MacPrices.net

Amazon offers 13-inch MacBook Air for $899, $...
Amazon.com has the 13″ 1.4GHz 128GB MacBook Air on sale for $100 off MSRP including free shipping: - 13″ 1.4GHz 128GB MacBook Air: $899.99 Read more
Apple resting On Its iPhone Laurels? – The ‘B...
Apple calls its new iPhone 6 and 6 Plus “The Biggest Advancements in iPhone History,” but does reality live up to the hype? “Seldom have so many waited so breathlessly for so little,” tweeted veteran... Read more
Roundup of Apple Mac and iPad Education disco...
Purchase a new Mac or iPad at The Apple Store for Education and take up to $300 off MSRP. All teachers, students, and staff of any educational institution qualify for the discount. Shipping is free,... Read more
Apple Boycotts German Magazine Computer Bild...
Apple has revoked its PR accreditation of Germany’s Computer Bild, Europe’s best-selling PC magazine, in reaction to Bild’s posting of a “#Bentgate” YouTube video. Axel Telzerow, editor in chief of... Read more
iPhone 6 & iPhone 6 Plus Available in Chi...
Apple has announced that iPhone 6 and iPhone 6 Plus will be available in China beginning Friday, October 17 from the Apple Online Store (http://www.apple.com), Apple’s retail stores, and an expansive... Read more
MacBook Airs on sale for $100 off MSRP, start...
Best Buy has the new 2014 MacBook Airs on sale for $100 off MSRP on their online store. Choose free home shipping or free local store pickup (if available). Prices valid for online orders only, in-... Read more
Apple Releases OS X Mavericks bash Update 1.0...
Apple has released a patch update for OS X Mavericks users to address the recently-detected “Shellshock” security bug in BSD UNIX’s bash shell. Apple says only a few Mac users who had manually... Read more
Pivotal Payments Ready for Apple Pay – FlexPo...
Pivotal Payments, a provider of merchant services and global payment processing solutions, has announced its proprietary FlexPoint platform will support credit and debit transactions through Apple’s... Read more
iStabilizer Announces Tabarm — First Friction...
iStabilizer, a specialist in universal lightweight compact tripods, steady cams, dollies, mounts, and remotes for smartphones, tablets, and cameras, announced today the iStabilizer tabArm, the first... Read more
IStabilizer Flex Smartphone Tripod Wins Usa T...
iStabilizer, a specialist in universal lightweight compact tripods, steady cams, and other products for smartphones, tablets, and cameras, has announced today that its iStabilizer Flex smartphone... Read more

Jobs Board

*Apple* Retail - Multiple Positions (US) - A...
Sales Specialist - Retail Customer Service and Sales Transform Apple Store visitors into loyal Apple customers. When customers enter the store, you're also the Read more
*Apple* Retail - Multiple Positions (US) - A...
Job Description: Sales Specialist - Retail Customer Service and Sales Transform Apple Store visitors into loyal Apple customers. When customers enter the store, Read more
Senior Event Manager, *Apple* Retail Market...
…This senior level position is responsible for leading and imagining the Apple Retail Team's global event strategy. Delivering an overarching brand story; in-store, Read more
*Apple* Solutions Consultant (ASC) - Apple (...
**Job Summary** The ASC is an Apple employee who serves as an Apple brand ambassador and influencer in a Reseller's store. The ASC's role is to grow Apple Read more
Project Manager / Business Analyst, WW *Appl...
…a senior project manager / business analyst to work within our Worldwide Apple Fulfillment Operations and the Business Process Re-engineering team. This role will work Read more
All contents are Copyright 1984-2011 by Xplain Corporation. All rights reserved. Theme designed by Icreon.