Chapter 1

User::Leave(KErrNone). This appears to work because you don't get
the error message. But in fact the error handler isn't called at all, so you don't
get some other useful things either.
So use iEikonEnv->LeaveWithInfoMsg() or, if you don't need an infomessage,
use the same function but specify a resource ID of zero.
In Chapter 13, the streams program includes an example of this pattern.
6.7 More on Panics
So far, I've dealt with how you can respond to errors that are generated by the environment
your program runs in – whether out-of-memory errors, files not being there, or bad user
input.
One type of error that can't be handled this way is programming errors. These have to be
fixed by rewriting the offending program. During development, that's usually your program
(though, like the rest of us, you probably start by blaming the compiler!). The best thing
Symbian OS can do for you here is to panic your program – to stop it from running as soon
as the error has been detected, and to provide diagnostic information meaningful enough for
you to use.
The basic function here is User::Panic(). Here's a panic function I use in my Battleships
game, from \scmp\battleships\control-ler.cpp:
static void Panic(TInt aPanic)
{
_LIT(KPanicCategory, "BSHIPS-CTRL");
User::Panic(KPanicCategory, aPanic);
}
User::Panic() takes a panic category string, which must be 16 characters or less
(otherwise, the panic function gets panicked!), and a 32-bit error code.
On the emulator debug build, we've seen what this does – the kernel's panic function
includes a DEBUGGER() macro that allows
the debugger to be launched with the full context from the function that called panic. That
gives you a reasonable chance of finding the bug.
On a release build, or on real hardware, a panic simply displays a dialog titled Program
closed, citing the process name, and the panic category and the number you identified.
Typically, it's real users who see this dialog, though you might be lucky enough to see it
during development, before you release the program. To find bugs raised this way, you
essentially have to guess the context from what the user was doing at the time, and the
content of the Program closed dialog. You'll need inspiration and luck.
You can shorten the odds by being specific about the panic category and number and by
good design and testing before you release.
Although technically it's a thread that gets panicked, in fact Symbian OS will close the entire
process. On a real machine, that means your application will get closed. On the emulator,
there is only one Windows process, so the whole emulator is closed.