A road named NoNameUno

Continuing last note ...

What I found from my previous experiences that even if we format or simply add one char in a comment, and save source file, we should really go thru the whole process of building the software and run thru a series of test processes. This is bit strict, but for any production quality software we really should follow this process. 

On top of it, quality assurence process should not tuch the source and / or binary. They should mostly use as built software and do all sorts of error testing and analysis. There are variations of this approach, but mostly this reduces confusions among team members.

Most of the code we do for error conditions and possible actions are of IF-THEN-ELSE, and there are TRY-CATCH type patterns. One example is, for example, memory allocation. How do I make the system to force a failure in memory allocation API that was provided by the system library?

One approach is that we can wrap anysuch system calls in another functions and fail it there, but that requires extracode, and managing between Release and Debug build could be unnecessary work.

I use some simple macros in the code itself to make sure the error paths works. As an example, let's say I want to force an error on a memory allocation, I use the following pattern.

if (TRIGGER  ( (memVa = malloc(n) ) == NULL )  ){

HandleTheErrorPlease(...);

}else {

/* success */

DoTheProcessing (...);

}

This is just a simple example for triggering, and depending on what kinda triggering and at what point in time I want to trigger, I can inject error conditions at different code paths with different types of error.

Now what I get out of it?

1) Does it handle errors correctly?

2) No code changes, between production and test codes.

3) Total code coverage - to eliminate dead code.