Completion of error handling

[elfring]

I have looked at a few source files for your current software. I have noticed that some checks for return codes are missing.

Would you like to add more error handling for return values from functions like the following?

• pthread_once ⇒ lthread_create
• close ⇒ lthread_close

[halayli]

There is nothing lthread can do if close failed.

pthread_once will not fail since once_control & init_routine are always valid.

[elfring]

It will not be noticed that something unexpected went wrong if the return value is not checked after every function call. How do you think about the reaction "exit(errno)" or "abort()"?

[halayli]

I understand that. If close() failed there is nothing that needs to be done the it's safe to resume.

pthread_once will not fail and there is no need to check the return value. it's like checking 1+1 == 2 to make sure that 1+1 will always sum up to 2.

[elfring]

I see a general failure potential between the places of passing usually appropriate parameters and the processing for these values.

Function calls like "pthread_setspecific" and "pthread_mutex_unlock" are also similar update candidates if you care for complete exception handling.

[halayli]

pthread_setspecific needs to be checked, agreed.

pthread_mutex_unlock is guaranteed not to fail since it locks/unlocks in the same thread.

[elfring]

Would you like to take the probability into account that other threads might damage the data that was accurately passed? Are you concerned about effects from undesired buffer overflows?

How do you think about worries for occasional bit flipping?

[halayli]

At this point all bets are off. No checking in the world will save you from undefined behavior and corrupted memory.

[elfring]

I suggest to continue with checking of invariants for improved software correctness.

[halayli]

You check invariants when necessarily. There is no point in rechecking invariants every time, or at times when the invariant is guaranteed to be true. This can create the illusion of software correctness but has no added value.

[elfring]

The detection of a violated invariant gives you the opportunity to take a selected action instead of later effects from ignorance of implementation details.

Would you like to reduce the manual efforts for error code checking? How do you think about to encapsulate such issues as aspects?

[halayli]

I know that. I check return values when necessary only. Rechecking invariants has no value.

[elfring]

Would you like to detect every error situation as early as possible?

[halayli]

I would like to detect every error situation that can happen as early as possible.

[elfring]

You can let each return value acknowledge that a called function was executed in the way you expect here. I find that there is really no need to ignore error codes in most situations.

[halayli]

I only ignore return values when the success or failure of the call doesn't matter or when it's guaranteed to succeed in defined conditions.

Either way feel free to submit patches.

[elfring]

I find that you expect a bit too much about low failure rates for the huge variety of execution environments. How do you think about the approach "defensive programming" for your software library?

Would you like to reduce the efforts for error code checking by an exception class hierarchy?

Are there any chances to cooperate with a tool like "AspectC++"?

[halayli]

It's not about failure rates, it's about handling the failures that needs to be handled and figuring out if it's ok to resume or abort. If you have:

int x = 1 + 1;

Do you check if x == 2 before you continue?

Defensive programming is not about checking every call's return value or not. It's about assuming that things can & will fail and knowing how to recover from them. However, there are calls that will not fail when passed the right arguments. If the arguments are guaranteed to be passed right then there's no point in checking the return value.

Don't take what you read in standards too literally and apply it everywhere. It's a good exercise to have your own judgement process.

lthread is written in C so I am not sure why you are suggesting C++ tools.

If you feel that you can improve something, please submit a patch.

[elfring]

I would not check the example value once more with the shown literal usually. But I would try to ensure that such a computation result will be reused for further processing (which also includes conditional expressions).

I suggest to reuse C++ tools for the following reasons.

• Your software can eventually benefit from the use of exceptions.
• I would prefer to encapsulate error detection by pointcuts in the syntax that is supported by the tool "AspectC++" instead of the alternative "ACC". Can such an approach be integrated into your software build process?