This release note describes a new user default for controlling the behavior of applications in response to certain types of errors.

Note: This document was installed by Mac OS X Server in /System/Documentation/ReadMe. For a list of other release notes see:
Article 30925: " Mac OS X Server: Release Notes "

Application Errors

Certain types of application errors typically cause Yellow Box applications to exit abruptly. A new user default, NSExceptionHandlingMask, has been provided to control this behavior (for AppKit-based applications only) for three of the most common classes of such errors:

• uncaught NSExceptions;
• system-level exceptions (such as invalid memory accesses); and
• Objective C runtime errors (such as messages sent to freed objects).

defaults write NSGlobalDomain NSExceptionHandlingMask 63

System-level exceptions and runtime errors are handled by converting them into NSExceptions. NSExceptions generated in this manner will contain a stack trace in their userInfo under the key "NSStackTraceKey". Uncaught NSExceptions are handled by terminating the thread in which they occur (NSExceptions in an application's main thread are caught by NSApplication's top-level handlers).

In addition to the use of the NSExceptionHandlingMask user default to control this behavior for AppKit-based applications, the same functionality can also be accessed programmatically from both application and non-application Yellow Box executables by linking against the ExceptionHandling framework and calling

[[NSExceptionHandler defaultExceptionHandler] setExceptionHandlingMask:aMask]

Debugging Aids

For debugging purposes, it is also possible to use the same mechanism to report on NSExceptions that would otherwise be caught. The additional values that may be added to NSExceptionHandlingMask for this purpose are 64 for logging exceptions that would be caught by the top-level exception handlers in NSApplication, 128 for handling them, 256 for logging exceptions that would be caught at lower levels, and 512 for handling them. In these cases, handling an exception means nothing more than adding a stack trace to its userInfo under the key "NSStackTraceKey". Note that caught exceptions should be logged or handled only for debugging, not under normal circumstances, because doing so may generate large amounts of output, or alter the normal behavior of applications.

For further debugging purposes, it is possible to change the handling behavior for any condition handled by NSExceptionHandler so that the application will instead be halted to wait for a debugger to be attached. This is controlled by the NSExceptionHangingMask user default, constructed by summing values corresponding to the conditions under which the application should hang: 1 for uncaught NSExceptions, 2 for system-level exceptions, 4 for runtime errors, 8 for top-level caught NSExceptions, and 16 for other caught NSExceptions.

In addition, a tool called atos has been provided to convert numeric stack traces into symbolic form. See the atos(1) man page for details.