|
|
Is it possible to "Trap" a Panic?
| Fri, 2006-12-01 19:49 | |
|
Is it possible to "trap", or maybe override the error handling of a panic? Remember the days when you could write your own interrupt handling routine?
 If you're curious, here's the problem I'm running into. I have a utility function which logs text to both a file and the debugger output. The text is a string of sometimes unknown characters. It needs to be formatted, ala the printf function. But, since the text is unknown, if you wanted to print out the string "lsk#J%s5" you would cause a panic, because the '%s' in the string causes a USER 23 panic. This happens because the Format function will interpret the % as a formatting symbol instead of just a regular character. I understand there are ways, albeit inefficient ways, to get around this, but that's besides the point. There's also a second problem... the Format() function can't handle large strings (i.e. something like more than 500 bytes) or it panics as well. Here's the code if you are curious, though it's irrelevant to the question. Code: void PRINT_(const char* aText, ...) { VA_LIST list; VA_START(list, aText); // Sometimes the format list may have control/formatting codes in them, // which can cause a panic in FormatList(). TRAP does not work! TRAPD(err, buf8.FormatList(_L8(aText), list)); if (err) { buf8.Copy(_L(" * PRINT * Error in FormatList; cannot display string")); } // To debugger buf8.ZeroTerminate(); buf16.Copy(buf8); RDebug::Print(buf16); // To file; doesn't automatically print newline buf8.Append(_L("\n")); buf8.ZeroTerminate(); LOG_OUTPUT(buf8); } |
|
Forum posts: 83
the difference in a leave and a panic is :
Leave : a leave occurs under exceptional condition like out of memory or the absence/failure of a communiction link which essentially is not a programmers fault. a leave ca is always caught at the last TRAP in the call stack. the thread continues its execution from there on.
Panic : Some types of error are due to bad program code, such as passing an illegal parameter value. When this type of error is discovered, the thread associated with the erroneous program should be terminated. In Symbian OS, this is a referred to as a panic. The only proper response to a panic is to fix the program code. Never ever a program shoul be released which can result in a panic.
I hope this clears your doubt,
And reagrding your getting USER 23 panic refer SDK documentation, it says :
This panic is raised when any operation that moves or copies data to an 8 bit variant descriptor, causes the length of that descriptor to exceed its maximum length.
It may be caused by any of the copying, appending or formatting member functions and, specifically, by the Insert(), Replace(), Fill(), Fillz() and ZeroTerminate() descriptor member functions. It can also be caused by the SetLength() function.
warm regards
saurabh
Forum posts: 8
Any ideas?
Forum posts: 723
Cheers,
Tote
Gabor Torok
Software architect, Agil Eight (http://www.agileight.com/)
Blog: http://mobile-thoughts.blogspot.com/
Forum posts: 8
My goal is to handle such messages, to catch this kind of panics and exit gracefully, without showing the KERN-EXEC 3 message, for example.
Forum posts: 723
Also note (you might have already noticed) that there is a similar topic that also discusses this issue: http://forum.newlc.com/index.php?topic=14480.
Tote
Gabor Torok
Software architect, Agil Eight (http://www.agileight.com/)
Blog: http://mobile-thoughts.blogspot.com/
Forum posts: 1246
If it only shows on emulator, it is not much of a problem, or?
Forum posts: 8
If it only shows on emulator, it is not much of a problem, or?