Other than to note that if you have complex conditions for deciding when to do X, the resulting code has a minimum associated complexity. There is nothing wrong with what you call "trap-doors" and what I'd call "guard clauses". There is a lot wrong with having a lot of them - however you try to implement them.
There is a simple principle for analyzing the complexity of code that structured programming has taught for 3 decades now. Take a block. Add 1 for every decision, be that a loop, if, unless, case in a case statement... If you come to the end of the block and have a count over 10, that block of code is complex and is likely to become a source of trouble. Consider breaking it up, refactoring, redoing the logic, etc. (This is a rule of thumb. Sometimes no good rewrite is available. Flag the potential trouble-spot, check it carefully and move on.) Definitely don't stuff anything extra into that block - you don't want necessary complexity to become lost in a sea of extraneous material.
If I was at home I'd give you the name of the person who first came up with that complexity measure, the paper it appeared in, and a reference to the place in Code Complete that I read it. I'd even give you where it appears in both the first and second editions. Unfortunately I have no copies of Code Complete at hand, so I'm limited to just giving you the coding rule and the knowledge that I got it from Code Complete.
Cheers,
Ben