Welcome!

Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Native Development

Reply
Developer
Posts: 297
Registered: ‎10-30-2010
My Device: PlayBook
My Carrier: other

NECESSARY to check for BPS_SUCCESS and EXIT_SUCCESSes?

[ Edited ]

I like to keep my code very minimalistic. Man Happy

 

Is it really essential to have all checks like these?

 

if (EXIT_SUCCESS != bbutil_init_egl(screen_cxt, GL_ES_1, AUTO)) {
fprintf(stderr, "bbutil_init_egl failed\n");
bbutil_terminate();
screen_destroy_context(screen_cxt);
return 0;
}

 

to just:

 

bbutil_init_egl(screen_cxt, GL_ES_1, AUTO); ?

 

 

What is the initialization failure rate for the OpenGL, BPS and system apis?

Retired
Posts: 38
Registered: ‎10-26-2011
My Device: BlackBerry Bold 9900
My Carrier: Rogers

Re: NECESSARY to check for BPS_SUCCESS and EXIT_SUCCESSes?

We recommend you check all return values from BPS and other APIs.

BlackBerry Development Advisor
Posts: 683
Registered: ‎11-29-2011
My Device: PRIV
My Carrier: Rogers

Re: NECESSARY to check for BPS_SUCCESS and EXIT_SUCCESSes?

[ Edited ]

It's always good practise to check for failure return codes if a function provides them.  This allows your program to exit in a controlled manner rather than face an uncontrolled crash later on due to a segmentation violation, corrupted data, etc.

While you may not be seeing errors from these functions regularly, I don't imagine you're testing across all operating conditions (eg. low-memory, resources-unavailable, etc.)

Do you regularly check whether you get NULL pointers back from malloc(), for example?

 

Cheers,

Sean

Developer
Posts: 297
Registered: ‎10-30-2010
My Device: PlayBook
My Carrier: other

Re: NECESSARY to check for BPS_SUCCESS and EXIT_SUCCESSes?

[ Edited ]

smcveigh wrote:

It's always good practise to check for failure return codes if a function provides them.  This allows your program to exit in a controlled manner rather than face an uncontrolled crash later on due to a segmentation violation, corrupted data, etc.

While you may not be seeing errors from these functions regularly, I don't imagine you're testing across all operating conditions (eg. low-memory, resources-unavailable, etc.)

Do you regularly check whether you get NULL pointers back from malloc(), for example?

 

Cheers,

Sean


I always check to make sure the return values are correct for the basic and critical functions.

 

My suggestion is, the API could be simplified so that instead of intimidating names like EXIT_SUCCESS BPS_SUCCESS, it could simply return 1 on success or 0 on failure. And the error code if applicable could be set to a pointer.

 

It would look more friendlier in this way.

 

 

if (!bps_function(param1, param2, &errorCode))

exitApplication()

 

 

BlackBerry Development Advisor
Posts: 683
Registered: ‎11-29-2011
My Device: PRIV
My Carrier: Rogers

Re: NECESSARY to check for BPS_SUCCESS and EXIT_SUCCESSes?

[ Edited ]

AppStoreLover wrote:

 

if (!bps_function(param1, param2, &errorCode))

exitApplication()

 

 


 

Given that stdlib.h defines EXIT_SUCCESS as 0 and bps.h defines BPS_SUCCESS similarly, you are definitely free to do something like:

if (bps_function(...)) { exitApplication(); }

 

The reason for using #defines or constants is to hide the numeric details and to give an identifier that is instantly understandable.  It also allows for these identifiers to take on different values if necessary on different processor architectures, platforms, etc.

 

Cheers,

Sean

 

Retired
Posts: 38
Registered: ‎10-26-2011
My Device: BlackBerry Bold 9900
My Carrier: Rogers

Re: NECESSARY to check for BPS_SUCCESS and EXIT_SUCCESSes?


AppStoreLover wrote:

 

My suggestion is, the API could be simplified so that instead of intimidating names like EXIT_SUCCESS BPS_SUCCESS, it could simply return 1 on success or 0 on failure. And the error code if applicable could be set to a pointer.

 


The UNIX and C convention is to return 0 on success.  If you look to see what BPS_SUCCESS is defined as, you'll find that it's 0, same for EXIT_SUCCESS.

 

For failure, the convention is to return non-zero (usually -1), and set the global variable errno to a relevant value that you can look up in errno.h.  This is also what BPS functions do, as BPS_FAILURE is defined as -1.