Forums | developer.brewmp.com Forums | developer.brewmp.com

Developer

Forums

Forums:

Any idead about possible error handling framework for BREW applet other than functions returning error code

Thanx in advance...

regds,
Nilesh

What you are trying to achieve?

What you are trying to achieve?

I dont want to return error code from funcs, as this will requires too much IF-ELSE or SWITCH-Case blocks in my code which will make code more complex.

I dont want to return error code from funcs, as this will requires too much IF-ELSE or SWITCH-Case blocks in my code which will make code more complex.

one idea:
{
....//code
IS_SUCCESS (someError, label);
....//code
IS_SUCCESS (anotherError, label1);
....//code
label:
label1:
return err;

where IS_SUCCESS is defined like:
#define IS_SUCCESS(eCode, exceptionTag) \
do { \
if ( (eCode ) != 0 ) { \
goto exceptionTag; \
\
while (0)
One potential problem with this approach is that goto (as well as jumping to a case label) crosses initialization - so proper scoping has to be used for initialization sections.

one idea:
{
....//code
IS_SUCCESS (someError, label);
....//code
IS_SUCCESS (anotherError, label1);
....//code
label:
label1:
return err;

where IS_SUCCESS is defined like:
#define IS_SUCCESS(eCode, exceptionTag) \
do { \
if ( (eCode ) != 0 ) { \
goto exceptionTag; \
\
while (0)
One potential problem with this approach is that goto (as well as jumping to a case label) crosses initialization - so proper scoping has to be used for initialization sections.

I also use the technique that radub describes, although I tend to only use one label that is always named 'exit:' so that I can include it in the macro definition. More than one exit point is always more difficult, in my opinion, to read and debug. Then I can use a macro like EXIT_NOT_SUCCESS(result);
If you want to use gcc, you could maybe spend a lot of time trying to get exceptions to work. Seems like a waste though because the mod files become much larger, maybe even prohibitably so.
-Aaron

I also use the technique that radub describes, although I tend to only use one label that is always named 'exit:' so that I can include it in the macro definition. More than one exit point is always more difficult, in my opinion, to read and debug. Then I can use a macro like EXIT_NOT_SUCCESS(result);
If you want to use gcc, you could maybe spend a lot of time trying to get exceptions to work. Seems like a waste though because the mod files become much larger, maybe even prohibitably so.
-Aaron

If you see windows directX programs or COM style program, you will find that often developers prefer to use "goto" to some error label if something goes wrong.
This allows single point exit, ensures proper cleanup and error handling and provides you more readable and maintainable code.
It is a matter of individual programming style.
ruben

If you see windows directX programs or COM style program, you will find that often developers prefer to use "goto" to some error label if something goes wrong.
This allows single point exit, ensures proper cleanup and error handling and provides you more readable and maintainable code.
It is a matter of individual programming style.
ruben

Browsing CUJ archive (cuj.com) you can find a couple of interesting C/C++ frameworks emulating the try/catch mechanism ( setjmp/longjmp based) as well as some "goto" wrappers.

Browsing CUJ archive (cuj.com) you can find a couple of interesting C/C++ frameworks emulating the try/catch mechanism ( setjmp/longjmp based) as well as some "goto" wrappers.

I don't think that setjmp/longjmp will work in BREW. No static variables, and way too risky given the quirks of the event model.
But I'm sure someone can prove me wrong...
-Aaron

I don't think that setjmp/longjmp will work in BREW. No static variables, and way too risky given the quirks of the event model.
But I'm sure someone can prove me wrong...
-Aaron

IThread is implemented using setjmp/longjmp - but it's QC's implementation, of course! I think you can use an applet-relative "global" jump buffer but callback rollback might be tricky indeed...

IThread is implemented using setjmp/longjmp - but it's QC's implementation, of course! I think you can use an applet-relative "global" jump buffer but callback rollback might be tricky indeed...