>>From: "Pascal Levy" <[EMAIL PROTECTED]> <SNIP> >> The way to handle this is not to >> allow an exception to escape from your comparison function, but to signal >> the failure back to the caller some other way, such as via SysQSort()'s >> _other_ parameter. Such is life when you're calling a C function. > >From: John Marshall <[EMAIL PROTECTED]> >There is no way to stop the sorting process from within the callback >function. And exception entry code is slow. The callback beeing called about >n*log(n) times, I'd rather catch exceptions globally than locally. > >> Thus you avoid this memory leak on existing ROMs now. >>No"improvements" needed. > >Yes, improvement is needed !
Actually the only problem I see here is your desire to handle exceptions globally. This is a case where you need to handle the exception locally or just use error checking. And that's generally a good idea when you are writing a function called by a function you have no control over. You should try and recover from the error so the sort can continue. Also, after an unrecoverable exception/error occurs, on subsequent calls to your function it should return whatever code is required to minimize completion, probably (1) in this case, so you only have (n) calls not n*log(n) to complete the sort. Roger Stringer Marietta Systems, Inc. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
