At 7:56 AM -0400 9/23/02, Stringer wrote: >Time to put more (or some) error checking code into your program. >Check for NULL returns in particular, then pop-up an error screen >of your own design to alert you to the error.
Here are a couple of quick-and-dirty things I sprinkle through code. They're not real error handling, but they're a bit more of a clue when Gremlins catches something. #define ASSERT(test) ErrFatalDisplayIf(!(test), "assert failed") and then use the assert to test any situation that might cause problems, such as internal inconsistencies or meaningless results. It still throws a fatal error/reset on the device, but at least tells you where in your code the problem is, instead of giving an OS line number. If you like, for release you can #define ASSERT(test) Another thing I've done is written my own wrapper for MemPtrNew. Originally I used it to verify matchup of New/Free calls, but that's less important now that POSE tracks memory leaks. I also use it to handle out-of-memory conditions in one place in the code. Hal -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
