Unreachable code: error or warning?

Question

This is a language design issue:

What do you think, inaccessible code (in programming languages ​​in general) should raise a warning (ie, “report problem and compilation anyway”) or an error (“refuse compilation”)?

Personally, I strongly feel that this should be a mistake: if a programmer writes a piece of code, he should always be with the intention of actually running it in some kind of script. But the C # compiler, for example, disagrees with this and simply reports a warning.

Note. I understand that finding good dead code is a very difficult problem, but this is not the focus of this issue.

Here are some sample code snippets where some statements are clearly unattainable:

return; foo(); 

-

 throw new Exception(); foo(); 

-

 if (...) { return; } else { throw new Exception(); } foo(); 

Answer 1

Generally speaking, this should be a mistake.

The only exception comes to my mind:

 if (false) { doStuffThatITemporarilyDisabled(); } 

Some developers may complain if your compiler refuses to compile for such code.

Answer 2

An error means that the compiler is physically unable to handle your code.

A warning means that the compiler is able to work with your code, but it believes that what you wrote is in some way wrong.

It seems to me that this is very clear to me - this should be a warning.

Also, for the case where I decided to shorten the method for debugging purposes:

 public bool ShowMenu() { return true; /* The standard implementation goes here */ } 

I know it incorrectly, but for the compiler to ask me also to comment that the code will be just a pain.

Answer 3

Very often dead code is created intentionally during debugging - a compiler that prevents this is unlikely to be popular among its users.

Answer 4

I think the warning is coming up. The user can then decide to use your OTHER switch, which says “treat all warnings as errors” when he makes the Release build. Empowering a developer is always better than imposing almost random options on him.

Answer 5

I think this should be a warning.

Generally speaking, the general rule is that "you should treat warnings as errors." If I inadvertently write an unreachable code, I will see it in the warnings and fix it anyway.

However, sometimes, as Neil says, you intentionally create dead code for debugging purposes or for any reason. I really, really hate it if the compiler doesn't let me do this.

Answer 6

If you specify the language:

• Believes that dead code is an error.
• Doesn't support C-style text-level preprocessing
• Disadvantages of block style comments that can be inserted with line style comments

... then it really suck. It is imperative to be able to disable large blocks of code without having to physically cut them out of the file.

Answer 7

I would prefer (provably) unreachable code to get a warning or notification (like a warning, but without negative connotations). Mostly because it simplifies code generation.

Answer 8

A good reason for this code to be in the development phase: you want to temporarily disable certain code, but you still want this code to be checked for syntax.

eg:

 int i = 2, j = 3; int result = 0; // FIXME: Commented out for now because I have to recheck calculation if (false) { result = i*2+j+3+i*j; } System.out.println("Result of difficult calculation = "+result); 

If you put the list "result = i * 2 + j + 3 + ij;" just in / comments * / , you are sure that when you delete or rename certain variables (e.g. i), you do not get an error.

Answer 9

This should be a default warning with a compiler flag that allows it to be treated as an error. The requirement that he be invariably one or the other does not matter.

Answer 10

I think this should be a warning for the same reason as Roalt. A good compiler should also exclude compilation of this code.

Answer 11

I still don't understand why Java implements dead code as an error. I use C and Objective-C that have preprocessors, so I can easily use preprocessor directives to include (or mask) a function / method, for example:

 // C code #define ENABLE_FOO //Comment off this to turn off foo(void); int foo(void) { #ifdef ENABLE_FOO // Do actual stuff. int returnVaue = 2; // ... return returnValue; #else return 0; // Turned off #endif } // Compiling using clang, enforcing dead code detection: // clang main.c -Wall -Werror 

or, as in Objective-C, with reflection available:

 // Class #define MYCLASS_ENABLE_FOO // Comment off to enable -[MyClass foo] @interface MyClass : NSObject #ifdef MYCLASS_ENABLE_FOO - (int)foo; #endif @end // The like is done in implementation. // Invoking: int main(int argc, char **argv) { MyClass *object = [[MyClass alloc] init]; int value = ([object respondsToSelector:@selector(foo)]) ? // Introspection. [object foo] : 0; printf("Value: %d", value); return 0; } 

Answer 12

The answer is that the final decision that an unreachable code is causing an error or warning should be left to the developer. The compiler must allow either.

In the case of a product release code, the balance makes it an error. No production program should contain unreachable code.

In the case of code for debugging / testing, the balance makes it a warning. It is very convenient to be able to disable parts of the code for debugging or testing.

The foregoing applies only to handwritten code. In the case of code that was generated by an automatic tool, balance helps to prevent or ignore it. Generating code that includes unreachable parts has no particular adverse effects and can be extremely difficult to avoid.