|
|
Handling Exceptions at Thread level
Handling Exceptions at Thread level: Typically we can have divide by zero, access violation as some of the exceptions in our application. By default when an exception occurs, then it's been passed to the Kernel for handling. The default action is to panic the offending thread.
If a thread has an exception handler, then the handler is executed in the context of the thread on which the exception is raised; control returns to the point of exception. Even in this case, the exception may be passed to the kernel, if in case; the exception handler will not handle the type of exception identified by the TExcType enumeration.
A thread can raise exception by calling RThread::RaiseException(). In this case, it has two different behaviors depending on whether it's been raised on the caller's own thread or on another thread. If it's on same thread, then if that exception is handled, then there won't be any problem, else KERN-EXEC 3 panic will occur. If RaiseException() is called on some other thread, then that thread ends with reason code KErrDied.
Here is an example code for the use of above concept:
{
switch (aType)
{
case EExcAccessViolation:
{
console->Printf(_L("Access Voilation Exception\n"));
User::After(TTimeIntervalMicroSeconds32(1000000));
User::Leave(KErrGeneral);
break;
}
//You can add more exceptions which are defined in e32const.h in TExcType Enumerator
}
}
void doExampleL()
{
console = Console::NewL(KAPConsoleTest, TSize( KConsFullScreen, KConsFullScreen));
CleanupStack::PushL(console);
//Set the Exception Handler
User::SetExceptionHandler(MyExceptionHandlerL, KExceptionFault);
int* ptr = NULL;
(*ptr)++;
CleanupStack::PopAndDestroy(console);
}
TInt E32Main()
{
__UHEAP_MARK;
CTrapCleanup* cleanup = CTrapCleanup::New();
TRAPD(error, doExampleL());
__ASSERT_ALWAYS(!error, User::Panic(KAPConsoleTest, error));
delete cleanup;
__UHEAP_MARKEND;
return 0;
}
Above program will raise EExcAccessViolation and it will be caught by the exception handler. You can continue with executing normally after catching the exception if it's not a problem, or you can terminate the application. For example in the above code, I am leaving from the function so that TRAP will catch that leave and my program will end with error. ( __ASSERT_ALWAYS will check the return value and panic again)
> Handling Exceptions at Thread level
> Handling Exceptions at Thread level
Th API SetExceptionHandler is member of RThread class till Symbian 8.0. And from 9.0 onwards this api is part of User Class. So, you wont be able to compile it on older versions of Symbian. Just change it to RThread::SetExceptionHandler()
In 8.0 It is:
TInt RThread::SetExceptionHandler(TExceptionHandler* aHandler,TUint32 aMask);
And from Symbian9.0 onwards, it is static member of User Class with below prototype:
TInt User::SetExceptionHandler(TExceptionHandler aHandler, TUint32 aMask);
Regards
Girish
> Handling Exceptions at Thread level
Girish Bhai
Your Articles are awesome i have read most of them , i am new to symbian and want to be an experience person could u guide me how to get such a deep knowledge about symbian , My name is Bharat uppal , it would b great if keep in touch with me regularly so tht i can learn a lot my id is as follows
bharatuppal@gmail.com
bharatuppal2000@yahoo.com // please add me in ur list
please guide me which material to refer for bing so experienced in symbian .
I hope you wud help me
> Handling Exceptions at Thread level
Girish Bhai
Your Article are awesome i have read most of them , i am new to symbian and want to be an experience person could u guide me how to get such a deep knowledge about symbian , My name is Bharat uppal , it would b great if keep in touch with me regularly so tht i can learn a lot my id is as follows
bharatuppal@gmail.com
bharatuppal2000@yahoo.com // please add me in ur list
please guide me which material to refer for bing so experienced in symbian .
I hope you wud help me
> Handling Exceptions at Thread level
> Handling Exceptions at Thread level
_E32Startup is the one which calls E32Main of my EXE. This will be called with reason code as KModuleEntryReasonThreadInit.
With in my EXE, When it is executing "(*ptr)++;" it will cause an exception which will call NThread::Exception () and this will cause the execution of NThread__HandleException() function.
This function will check, whether user registered his own exception handler. If so, it will call , _E32Startup again with reason code as KModuleEntryReasonException.
This time it will call User::HandleException() with the information given. User::HanldeException will issue Exec call which will call my exception handler MyExceptionHandlerL().
My exception Handler will leave with KErrGeneral. So immediate nested TRAP will be called, which is in my E32Main. So, control comes back to my own E32Main and after that it Panics as I have __ASSERT_ALWAYS in my E32Main.
If I comment User::Leave(KErrGeneral); with in my MyExceptionHandlerL(), then after the execution of MyExceptionHandlerL() control will come back to the statement which has caused the Exception, that is "(*ptr)++;". Again it will try to execute the same statement, again one more exception and this loop continues...!!!!
So, I have User::Leave which is the default behavior in my exception handler.
So, answer to your requery is, User::Leave in my exception hadler will come back to my own TRAP in E32Main and my exe will Panic. The best way of getting the clear picture is to debug the code and see the control flow from _E32Startup.
Regards Girish
Handling Exceptions at Thread level