Hi,
I had the same concern and tried a similar kind of fix few weeks back. But because of the following explanation it seems we have to bear with the current code.

Suppose we have implemented your fix. say we call to functions x, y and z in that order. Say inside function x it set an error code status.

Now we call y. Inside y() we neglect the error code and say we do even a database commit. Now we call to z(). At the beginning of z say we do an param check. If all parameters are good to go it should pass param checks. But it return an error (because of previously set error status in function x) even when all parameters are good. This is unfair for function z() and it is also misleading.

So the best thing to do is to handle error status before calling any important function which has param checkings etc. For example in function y() we have even done a database commit neglecting the error status which is not good.

thanks
Damitha.

Dimuthu Gamage wrote:

Hi devs,

Currently in AXIS2_PARAM_CHECK, if the param is null we set the status code to AXIS2_FAILURE and if not null set the status code AXIS2_SUCCESSS

#define AXIS2_PARAM_CHECK(error, object, error_return)                  \
    if (!object)                                                        \
    {                                                                   \
AXIS2_ERROR_SET_ERROR_NUMBER(error, AXIS2_ERROR_INVALID_NULL_PARAM); \
        AXIS2_ERROR_SET_STATUS_CODE(error, AXIS2_FAILURE);              \
        return error_return;                                            \
    }                                                                   \
    else                                                                \
    {                                                                   \
        AXIS2_ERROR_SET_STATUS_CODE(error, AXIS2_SUCCESS);              \
    }


My question is, is it ok to set the status code to AXIS2_SUCCESS,
Because
1. If we are in happy path, the status code is already AXIS2_SUCCESS, we don't need to explicitly set that. 2. The macro can overwrite the status, That is if the status is already set to failure by an early case, this macro will overwrite the status to SUCCESS which is wrong.

So my suggestion is to remove the else part from that macro?. Please let me know your ideas, I may be wrong on this.

Thanks
Dimuthu



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to