A road named NoNameUno

So what we have so far?

1. We want software mechanism to embed error or fault injection to see how our module handles, at least, some of the basic stuff.
2. It is not enough to say, after using API we check for error, and take the appropriate execution path. Instead, we must exercise the error handling paths by injecting some basic errors.
3. As always, the code to inject errors has to be minimally invasive in the sense that the code can to production, but will never generate the code for error injection. While under test, we can inject those errors as required.
4. Alternatively, use external error injections as an ad hoc fashion.

All the triggers are of the first type of error injection. It is inside the production code, just does not need to be compiled into the production binary. 

On the otherside of the fence, is to use separate module/infrastructure etc., to inject errors. For kernel programming in platforms where filter and/or stream drivers infrastructures are available, they are sometime good alternatives. For example, under windows, I've used filter drivers to inject errors on IRPs. For linux/unix, I worked on stream drivers that take the burden of injecting errors to main device drivers at will.

That's it for a basic error injection and design to debug!

Happy new year to all!