Texas Instruments TI89 Developer Guide - Page 141

Chapter 10: Error Handling 99 10.6.2. 10.6.3. Specifically: • Do not execute a return statement out of a TRY block. • Do not execute a goto statement out of a TRY block. Executing any code which bypasses popping the TRY stack will probably cause the calculator to crash the next time an error is thrown. There is a way to return or goto out of a TRY block if you absolutely must. The trick is to pop the TRY stack yourself before leaving the TRY block. This can be accomplished by calling ER_success just before the goto or return statement. Referencing Auto Variables in ONERR/FINALLY Blocks The TRY macro saves many of the CPU registers on its execution context stack. Consequently, when an error is thrown, all variables which reside in CPU registers are reset to their contents before the TRY macro was called. This is only a problem with auto variables - global and static variables are never kept in CPU registers. If code in an ONERR or FINALLY block needs the value of a variable set in the TRY block, the code must arrange to make sure the C code optimizer does not put that variable in a CPU register. This can be accomplished by declaring such variables to be volatile. So, remember this rule: Auto variables changed in a TRY block must be declared volatile if they are referenced in an ONERR or FINALLY block. Where Not to Throw Errors One last reminder: • Do not throw errors while processing events CM_START, CM_ACTIVATE, CM_FOCUS, CM_UNFOCUS, CM_DEACTIVATE, CM_QUIT, CM_WPAINT, CM_INSTALL, CM_UNINSTALL, CM_PACK, CM_UNPACK, CM_INIT, or CM_MODE_CHANGE. See section 10.2. Delayed Error Messages for details on how to signal exceptions under these circumstances. TI-89 / TI-92 Plus Developer Guide Not for Distribution Beta Version January 26, 2001