Chapter 10: Error Handling
99
TI
-
89 / TI
-
92 Plus Developer Guide
Not for Distribution
Beta Version January 26, 2001
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.
10.6.2. 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.
10.6.3. 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.
To Next Page
Loading...
Need help?
General
