Some things to consider; 1. Each nested try-catch will consume an extra 56 bytes of stack for the ErrExceptionType struct. 2. Every try-catch will inline 66 bytes of overhead code, including 4 system traps. 3. The try-catch mechanism, as implemented, requires A5 globals, so cannot be used when globals are not present. 4. If your code is running "in the background" and has not accounted for globals and appInfo, and is not related to the current foreground application, then it will mistakenly try to use the wrong exception list. 5. If you are using C++, destructors will not be invoked to clean up your stack when you trap to ErrThrow(). The compiler does not know to invoke destructors, expecting a return from the trap to ErrThrow(). None of these are significant in a small foreground application. In a large, background or performance bound application, the issues and overhead can be significant.
On Thu, Jul 10, 2008 at 6:31 AM, P. Douglas Reeder <[EMAIL PROTECTED]> wrote: > I have had good success using the macros ErrTry-ErrCatch and ErrThrow, > defined in the PalmOS headers. There does not appear to be a significant > hit to program size. Since they allow you to throw a 32-bit value, I encode > the Palm OS error code in the lower 16 bits, the source code line number in > the next 12 bits, and the source code file in the upper 4 bits. (Since > armlets can't throw exceptions, you don't need to assign a number to their > source code files -- so far, I haven't had more than 16 source code files > that threw exceptions.) > > This nets most of the advantages of exceptions -- simplified error > checking. You can't do an exact equivalent to a "finally" clause, but you > can catch an exception, do clean up, and throw the exception again from the > ErrCatch block. > > I have not, however, tried using them with C++. > > > > On Jul 9, 2008, at 12:14 PM, Michal Seliga wrote: > > for even medium size projects i always had to always switch it off because >> exception tables and such things consume a lot of memory for global >> variables which is of limited size. because of this you must also be sure >> you will not use it in launchcodes where globals are not available >> >> if your application is relatively small then you may try it. and if you >> will hit global variables size limitation you will know its not way to go >> >> my advice - don't use exceptions. better check return codes of functions >> and make if() whenits needed. it is faster and much simpler to debug in case >> of problems >> >> > -- > For information on using the ACCESS Developer Forums, or to unsubscribe, > please see http://www.access-company.com/developers/forums/ > -- [Jeff Loucks, Gig Harbor, WA, USA] -- For information on using the ACCESS Developer Forums, or to unsubscribe, please see http://www.access-company.com/developers/forums/
