[ACCEPTED]-Unreachable code: error or warning?-language-design

An error means that the compiler is physically unable 10 to deal with your code.

A warning means that the compiler 9 is capable of dealing with your code, but 8 it believe that what you have written is 7 wrong in some way.

It seems pretty clear 6 cut to me - it should be a warning.

Besides, what 5 about the case where I've decided to shorten 4 a method for debugging purposes:

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

I know its 3 wrong, but for the compiler to ask me to 2 also comment out that code would just be 1 a pain.

It is very common to create dead code intentionally 3 when debugging - a compiler that prevents 2 this is unlikely to be popular with its 1 users.

Generally speaking it should be an error.

One 3 exception comes to my mind however:

if (false) {
  doStuffThatITemporarilyDisabled();
}

Some 2 developers might complain if your compiler 1 denies compilation for code like that.

I think a warning is appropriate. Then 5 the user can decide to use your OTHER switch 4 that says "treat all warnings as errors" for 3 when he does a Release build. Empowering 2 the developer is always better than forcing 1 your essentially random choices onto him.

I think it should be a warning.

Generally 7 speaking, the common rule is that 'you should treat warnings as errors'. If I 6 unintentionally write unreachable code, I 5 will see it in the warnings, and fix it 4 anyway.

However, sometimes, like Neil says, you 3 intentionally create dead code, for debugging purposes 2 or whatever reason. I'd really, really hate 1 it if the compiler would not let me do that.

If you language specifiction:

• Considers dead code to be an error
• Doesn't support C-style "text-level" preprocessing
• Lacks block-style comments that can nest with line-style comments

... then it 3 will truly suck. It's imperative to be able 2 to disable large blocks of code without 1 having to cut them out of the file physically.

I'd much prefer (provably) unreachable code 4 to produce either a warning or a notice 3 (like a warning, only without negative connotations). Mainly 2 because this makes automatic code generation 1 slightly easier.

A good reason for having that code is during 7 the development phase: you want to temporarily disable 6 certain code, but you still want this code 5 to be checked on syntax.

for example:

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 4 put the list "result = i*2+j+3+ij;" just in / comments 3 */, you're pretty sure that when you remove 2 or rename certain variables (e.g. i), you 1 do not get an error.

It should be a warning by default with a 3 compiler flag that allows it to be treated 2 as an error. Requiring it to be unchangeably one 1 or the other is inconsiderate.

I think it should be a warning because of 3 the same reason as Roalt said. A good compiler 2 should also exclude this code from being 1 compiled.

I an still not clear why Java is implementing 5 the dead code as an error. I use C and Objective-C, which 4 have preprocessors, thus I can easily use 3 preprocessor directives to enable (or mask) an 2 function/method, like:

// 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, like in Objective-C, with 1 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;
}

The answer is that the final decision as 17 to whether unreachable code triggers an 16 error or a warning should be left in the 15 hands of the developer. The compiler should 14 allow either.

In the case of production release 13 code the balance favours it being an error. No 12 production program should contain unreachable 11 code.

In the case of debugging/testing code 10 the balance favours it being a warning. It 9 is extremely convenient to be able to disable 8 parts of the code for debugging or testing.

The 7 above refer only to hand-authored code. In 6 the case of code that has been generated 5 by an automated tool, the balance favours 4 it being a warning or ignored. The generation 3 of code that includes unreachable portions 2 has no particular adverse consequences and 1 may be extremely hard to avoid.