locked
Embedded statement cannot be a declaration or labeled statement

    Question

  • Why? I really don't understand why this code is a compiler error:

    if (true)

    int i;

    and this is legal:

    if (true) {

    int i;

    }

    It does the same thing. I understand why some argue that

    return;

    int i;

    should be illegal (it is in Java but is only a warning in C#), but why won't compilers just listen to what the programmer is saying and do it? At least this should be a warning like having code after a return statement. I just want to understand the reasoning behind this error.

    Also, I know someone is going to say "why would you want to do that." I have two answers: an easy way to add a breakpoint for debugging, and because I can.

    Saturday, June 23, 2007 8:18 PM

Answers

  • If you want to use this for debugging, you could replace the first version with:

    Code Snippet

    if (true)
    {}


    BTW, there are less chars to write .

    Set the breakpoint in the second line and you will be able to stop the debugger.

    About your second reason: since the compiler complains about the declaration, I guess you just can not do this. To me, this is reasonable as it makes no sense to the program to declare something one knows it will never be used!

    best,
    Saturday, June 23, 2007 8:40 PM
  • Because in the first version you could write:

    if(true)

    {

      int i;

      i = 1;

    }

     

    You can't do that in the second version:

    if(true)

    int i;

    i = 1; // CS0103

     

    The compiler has given you a little leeway in the first example because otherwise you'd get errors with this:

    if(true)

    {

     int i;

    #if TRACE

       i = 10;

    #endif

    }

    ...which exchanges error CS1023 with warning CS0168.

     

    One of the principles of C# (originally) was to provide programmers the ability to proactively write clear, more maintainable, and more manageable code.  if(true) int i; just isn't clear what the programmer intends to do with that block because there's nothing they can do with that block.

     

    As for breakpoints, there's no code to set a breakpoint on.

    Sunday, June 24, 2007 6:18 PM
    Moderator

All replies

  • If you want to use this for debugging, you could replace the first version with:

    Code Snippet

    if (true)
    {}


    BTW, there are less chars to write .

    Set the breakpoint in the second line and you will be able to stop the debugger.

    About your second reason: since the compiler complains about the declaration, I guess you just can not do this. To me, this is reasonable as it makes no sense to the program to declare something one knows it will never be used!

    best,
    Saturday, June 23, 2007 8:40 PM
  • Because in the first version you could write:

    if(true)

    {

      int i;

      i = 1;

    }

     

    You can't do that in the second version:

    if(true)

    int i;

    i = 1; // CS0103

     

    The compiler has given you a little leeway in the first example because otherwise you'd get errors with this:

    if(true)

    {

     int i;

    #if TRACE

       i = 10;

    #endif

    }

    ...which exchanges error CS1023 with warning CS0168.

     

    One of the principles of C# (originally) was to provide programmers the ability to proactively write clear, more maintainable, and more manageable code.  if(true) int i; just isn't clear what the programmer intends to do with that block because there's nothing they can do with that block.

     

    As for breakpoints, there's no code to set a breakpoint on.

    Sunday, June 24, 2007 6:18 PM
    Moderator
  • I doubt he wants to set the breakpoint programatically. What he means is that he can set a breakpoint in VS which will break only when the codition is satisfied. That is probably why he started wondering about the "problem".

    best,
    Monday, June 25, 2007 4:41 PM
  •  Gregor Berginc wrote:
    I doubt he wants to set the breakpoint programatically. What he means is that he can set a breakpoint in VS which will break only when the codition is satisfied. That is probably why he started wondering about the "problem".

     

    Exactly. I wanted the program to stop in a given condition so I could examine the local variables. To me at least, the first idea that came to mind would be something like this:

     

    if (myVar == 7)

      int i; // Put breakpoint here.

     

    That way, the normal operation of the program is not changed, and I get to examine the variables when myVar is 7. As for writing clear code, I think that's the job of the programmer, not the langauge specifications. In this case, the only reason this is an error is because someone decided it should be, not because it doesn't fit the language. Someone had to write code specifically to make this invalid. That's what bothers me here.

     

    I guess Gregor's original example is a valid way around this error, and actually is better than my way. Easier to type and C# allows it.

    Monday, June 25, 2007 11:05 PM