Hi, thanks for posting.
Structurally, what you are attempting to do is impossible without code coverage suppression (i.e. ncrunch comments, ExcludeFromCoverageAttribute, etc).
This is because a throw statement physically causes the runtime to return early from a method, leaving any code after it to be left unexecuted. As methods usually have debug information for NOP statements and other material at the end of the method, this results in code that is physically unexecuted by NCrunch.
It could technically be possible for NCrunch to ignore the unexecuted code and simply mark it as 'not code', thereby removing the black marks and allowing you to achieve 100% coverage with such a structure without the need for suppression comments. However, we do not do this for the following reasons:
1. It's a dirty lie. There is unexecuted code in your codebase. You may not consider this code important, and probably it's completely unreachable. But it's still unexecuted code, and that's still information. For NCrunch to cover this up would be for it to hide this information from you. This goes against the main goal of this project which is to inform people of how their code is behaving at runtime.
2. It's very hard for us to reliably determine which code in the method is unreachable when we instrument your code. We support 3 different compilers under NCrunch, and they all have their own weird patterns and edge cases. Any approach we take to do this would run the risk of unexpected behaviour under unforeseen edge cases. Given the sheer volume of code NCrunch executes for everyone, someone is bound to encounter something we haven't thought of and end up with a very strange result.
3. The instrumentation is a performance critical step. For us to determine whether the code is reachable would require additional parsing and complex processing of every method in your codebase. This would significantly impact build speeds for everyone using the product, regardless of whether they were interested in having this behaviour. We could do it with a config setting, but then there's a whole new setting when we already have far too many. I think also that most people would be far less interested in such an option if it made their builds run 40% slower.
As such, code coverage suppression comments would be the best solution I can offer given your situation.
