The macros that include ABORT will kill the app if they catch an exception, you will almost always want to use these. It saves a lot of time if we don't have to think about recovery strategies for calls. In order to code for recovery you'd have to understand something about the context of the code you are working in. If we start seeing exceptions killing the app it'll be easy to go back and code the calls that are throwing for recovery. That probably won't happen and if it does it'll probably be just 1-2 calls we need to not abort on.
More coming..There are currently three options for wrapping blocks of code. * Basic wrapping, use anywhere** block macros<code>NS_OBJC_BEGIN_TRY_ABORT_BLOCK</code>* identifying apple framework calls* <code>NS_OBJC_END_TRY_ABORT_BLOCK</code> * nonUse to wrap an entire method that returns an Obj-.mm filesC pointer** <code>NS_OBJC_BEGIN_TRY_ABORT_BLOCK_NIL</code>** <code>NS_OBJC_END_TRY_ABORT_BLOCK_NIL</code> * Used to wrap an entire method that returns an xpcom result code (<code>nsresult</code>)* whitespace* <code>NS_OBJC_BEGIN_TRY_ABORT_BLOCK_NSRESULT</code>* including nsObjCExceptions* <code>NS_OBJC_END_TRY_ABORT_BLOCK_NSRESULT</code> We will probably add another block type that returns nsnull, for use with methods that return xpcom objects, we might add others as the need arises. For any other place where you would like to wrap an entire method, you'll have to use the first basic block macros and refactor code to correctly to place the return statement after the end macro. This means you'll also have to scope any variables used in the return statement correctly. When you put a block macro into a method, it should contain a completely empty newline before and after it. The exceptions are when you are wrapping an entire method, there should be a completely empty newline after the start macro and before the end macro. The header file that contains these macros can only be used in an Obj-C context, for the most part this means files with the ".mm" extension. Mac-only files that contain Apple framework calls and do not end in ".mm" should be renamed to ".mm". We will devise a strategy for dealing with cross-platform files that contain Apple framework calls later.h
-Josh Aas
