Is there a way to get VS2008 to stop warning me about unreachable code?

Question

I have a few config options in my application along the lines of

const bool ExecuteThis=true;
const bool ExecuteThat=false;

and then code that uses it like

if(ExecuteThis){ DoThis(); }
if(ExecuteThat){ DoThat(); } //unreachable code warning here

The thing is, we may make slightly different releases and not ExecuteThis or ExecuteThat and we want to be able to use consts so that we don't have any speed penalties from such things at run time. But I am tired of seeing warnings about unreachable code. I'm a person that likes to eliminate all of the warnings, but I can't do anything about these. Is there some option I can use to turn just these warnings off?

Answer 1

To disable:

#pragma warning disable 0162

To restore:

#pragma warning restore 0162

For more on #pragma warning, see MSDN.

Please note that the C# compiler is optimized enough to not emit unreachable code. This is called dead code elimination and it is one of the few optimizations that the C# compiler performs.

And you shouldn't willy-nilly disable the warnings. The warnings are a symptom of a problem. Please see this answer.

Answer 2

First of all, I agree with you, you need to get rid of all warnings. Every little warning you get, get rid of it, by fixing the problem.

Before I go on with what, on re-read, amounts to what looks like a rant, let me emphasis that there doesn't appear to be any performance penalty to using code like this. Having used Reflector to examine code, it appears code that is "flagged" as unreachable isn't actually placed into the output assembly.

It is, however, checked by the compiler. This alone might be a good enough reason to disregard my rant.

In other words, the net effect of getting rid of that warning is just that, you get rid of the warning.

Also note that this answer is an opinion. You might not agree with my opinion, and want to use #pragma to mask out the warning message, but at least have an informed opinion about what that does. If you do, who cares what I think.

Having said that, why are you writing code that won't be reached?

Are you using consts instead of "defines"?

A warning is not an error. It's a note, for you, to go analyze that piece of code and figure out if you did the right thing. Usually, you haven't. In the case of your particular example, you're purposely compiling code that will, for your particular configuration, never execute.

Why is the code even there? It will never execute.

Are you confused about what the word "constant" actually means? A constant means "this will never change, ever, and if you think it will, it's not a constant". That's what a constant is. It won't, and can't, and shouldn't, change. Ever.

The compiler knows this, and will tell you that you have code, that due to a constant, will never, ever, be executed. This is usually an error.

Is that constant going to change? If it is, it's obviously not a constant, but something that depends on the output type (Debug, Release), and it's a "#define" type of thing, so remove it, and use that mechanism instead. This makes it clearer, to people reading your code, what this particular code depends on. Visual Studio will also helpfully gray out the code if you've selected an output mode that doesn't set the define, so the code will not compile. This is what the compiler definitions was made to handle.

On the other hand, if the constant isn't going to change, ever, for any reason, remove the code, you're not going to need it.

In any case, don't fall prey to the easy fix to just disable that warning for that piece of code, that's like taking aspirin to "fix" your back ache problems. It's a short-term fix, but it masks the problem. Fix the underlying problem instead.

To finish this answer, I'm wondering if there isn't an altogether different solution to your problem.

Often, when I see code that has the warning "unreachable code detected", they fall into one of the following categories:

1. Wrong (in my opinion) usage of const versus a compiler #define, where you basically say to the compiler: "This code, please compile it, even when I know it will not be used.".
2. Wrong, as in, just plain wrong, like a switch-case which has a case-block that contains both a throw + a break.
3. Leftover code from previous iterations, where you've just short-circuited a method by adding a return at some point, not deleting (or even commenting out) the code that follows.
4. Code that depends on some configuration setting (ie. only valid during Debug-builds).

If the code you have doesn't fall under any of the above settings, what is the specific case where your constant will change? Knowing that might give us better ways to answer your question on how to handle it.

Answer 3

What about using preprocessor statements instead?

#if ExecuteThis
    DoThis();
#endif

#if ExecuteThat
    DoThat();
#endif

Answer 4

Well, #pragma, but that is a but grungy. I wonder if ConditionalAttribute would be better - i.e.

[Conditional("SOME_KEY")]
void DoThis() {...}
[Conditional("SOME_OTHER_KEY")]
void DoThis() {...}

Now calls to DoThis / DoThat are only included if SOME_KEY or SOME_OTHER_KEY are defined as symbols in the build ("conditional compilation symbols"). It also means you can switch between them by changing the configuration and defining different symbols in each.

Answer 5

The fact that you have the constants declared in code tells me that you are recompiling your code with each release you do, you are not using "contants" sourced from your config file.

So the solution is simple: - set the "constants" (flags) from values stored in your config file - use conditional compilation to control what is compiled, like this:

#define ExecuteThis
//#define ExecuteThat

public void myFunction() {
#if ExecuteThis
    DoThis();
#endif
#if ExecuteThat
    DoThat();
#endif
}

Then when you recompile you just uncomment the correct #define statement to get the right bit of code compiled. There are one or two other ways to declare your conditional compilation flags, but this just gives you an example and somewhere to start.

Answer 6

The quickest way to "Just get rid of it" without modifying your code would be to use

#pragma warning disable 0162

On your Namespace, class or method where you want to supress the warning.

For example, this wont throw the warning anymore:

#pragma warning disable 0162
namespace ConsoleApplication4
{
  public class Program
  {
    public const bool something = false;

    static void Main(string[] args)
    {
        if (something) { Console.WriteLine(" Not something" ); }

    } 
 }

However be warn that NO METHOD inside this namespace will throw the warning again... and well.. warnings are there for a reason (what if it happened when you did NOT planned it to be unreachable?)

I guess a safer way would be to write the variables in a configuration file, and read them from there at the beginning of the program, that way you don't even need to recompile to have your different versions/releases! Just change the app file and go :D.

about the speed penalty.. yes.. making it this way would inquire in a speed penalty... compared to using const but unless you are really worried about wating 1/100 of a millisecond more.. I would go for it that way.

Answer 7

Here's a trick:

    bool FALSE = false;
    if (FALSE) { ... 

This will prevent the warning. Wait. I know there's all this "You should not use that, why have code that is not executed?". Answer: Because during development you often need to set up test code. Eventually you will get rid of it. It's important that code it is there during development, but not executed all the time.

Sometimes you want to remove code execution temporarily, for debugging purposes.

Sometimes you want to truncate execution of a function temporarily. You can use this to avoid warnings:

...code.. { bool TRUE = true; if (TRUE) return; } ...more code...

These things avoid the warning. You might say, if temporary, one should keep the warning in. yes... but again... maybe you should not check it in that way, but temporarily it is useful to get the warning out, for example when spending all day debugging complex collision code.

So, you may ask, why does it matter? Well, these warnings get very annoying when I press F4 to go to the first error, and get some damn 10 warnings first instead and I am knee deep in debugging.

Use the #pragma, you say. Well, that would be a good idea, except that I can't find a way to do that globally on my entire project.. or in a way that will work with Unity3D, which is what I code in C# for. Oh, how useful #include would be.

Never mind, use #if ! Well... yes... but sometimes they are not what you want. They make the code messy and unreadable. You have to bracket your code with them just right. Putting if(false) in front of a block is just so much easier... no need to delimit the block, the braces do that.

What I do is make a nice globally accessible FALSE and TRUE and use them as I need do avoid errors.

And if I want to check if I am actually using them, I can search for all references, or more crudely, but just as effectively, remove them and thus be forced to look at every occurrence of this little trick.

Answer 8

The easiest way is to stop writing unreachable code :D #DontDoThat