Can I protect against the failure of a block or symmetric cipher by chaining different techniques together? If so what implementation details should I be aware of?
Are some combination of ciphers better or worse than others?
In my case I'm not concerned about the CPU expense, but am more concerned about defending against unintentional programming errors or malicious crypto implementation (in hardware or software).
Unintentional programming errors can be defeated by extensively checking your code against test vectors before releasing it (or better yet, create a self-test routine). Note that this doesn't protect against a malicious attacker circumventing your self-test and inserting his backdoor at runtime, obviously.
Of course, there aren't any test vectors for cipher combos, but you can always create your own by running reference code (presumably, by the cipher designers or some authority like NIST).
As for malicious crypto implementations, there really is no way to know without sifting through the implementation line by line and verifying that nothing that shouldn't be there is, like a socket call to some random IP in a crypto library would probably raise a few eyebrows.
And as for crypto hardware, I think this has come up before a few times - if you can't trust your hardware cryptographic provider, it's game over already. Of course, if you're into that kind of stuff, you could recover the firmware and study it and check it for malicious code, but in general it's more or less a black box that you have to trust.
Your question seems to relate more to the correctness of the implementation (i.e. "getting the right answer") than of how to detect backdoors in crypto code.
Are some combination of ciphers better or worse than others?
When it comes to ensuring your code doesn't screw up and works fine, it doesn't matter, because of the all-or-nothing property of cryptographic primitives. It doesn't matter if your code screws up a single bit at the beginning, at the end, or at the middle - the result will be garbage in any case (or most of the time - if you are using keystream encryption this may not be true if your key schedule is correct).
If you don't trust your primitives, you can combine a number of techniques together (it really depends on the protocol though):
Isolation, to minimize the side effects each given implementation has on the environment besides those strictly defined by your input/output interface. Along with easy to catch deviations (e.g. a fishy socket call from a crypto library), you have several classes of side effects that are difficult to detect, either at the protocol level (e.g. covert channels) or at the implementation level (e.g. side channels, think of DPA). Each class has to be tackled specifically via code review, radiation analysis, etc.
Fault tolerance, to minimize the risk of a backdoor planted by an adversary or simple sloppiness. The most straightforward arrangement consists of assembling multiple and hopefully independent implementations from several vendors or sources, and do a majority vote on the result. Note that this approach is also pretty common to prevent external fault attacks.
Secret splitting, to minimize the risk of backdoors. You again arrange parallel primitive implementations from different vendors, but each works on a different piece data produced by a secret sharing scheme (e.g. Shamir's). All output are transmitted and not immediately combined as in the fault tolerance scheme. Of course, secret splitting and reconstitutions become critical points.
Finally, where randomness is involved, you must clearly separate random generation logic from deterministic logic. You cannot obviously do a majority vote on RNGs or on randomized protocols. Instead, you should apply the fault tolerance technique on the isolated RNGs, by combining the output of the various implementations in an entropy-preserving way (typically, a simple XOR would do).
