"fallthrough statement out of place" in `if` block inside `swicth` block

[Fumi Takeuchi]

Example code: https://play.golang.org/p/dVtPVt3oKt

---

I thought this code will work fine, but didn't, because of "fallthrough statement out of place" error.

Maybe `fallthrough` statement cannot be used in `if` block even if it's put inside `swicth` block)

So, my question is, which is better measure to solve this.

1. Use if-else instead of switch

2. Use goto (like this: https://play.golang.org/p/TILUCapta6) (I think this should be avoided. I would confise LABEL expression with one case)

3. Other (please comment)

Thank you.

[Jan Mercl]

On Tue, Aug 1, 2017 at 2:34 PM Fumi Takeuchi <fmodqu...@gmail.com> wrote:

> Example code: https://play.golang.org/p/dVtPVt3oKt

>
> Maybe `fallthrough` statement cannot be used in `if` block even if it's put inside `swicth` block)

True: It may be used only as the final non-empty statement in such a clause.

> 3. Other (please comment)

https://play.golang.org/p/8rL0zqaLP3

--

-j

[kultig...@gmail.com]

i believe you should avoid fallthrough statement except for auto-generated code.

it's obscure what you are trying to accomplish with that piece of code, but surely you can do it in a better way.

[Konstantin Khomoutov]

On Tue, Aug 01, 2017 at 05:54:28AM -0700, kultig...@gmail.com wrote:

> i believe you should avoid fallthrough statement except for auto-generated
> code.
>
> it's obscure what you are trying to accomplish with that piece of code, but
> surely you can do it in a better way.

They have its valid use to avoid situations like this:

| if cond1 && cond2 {
| if cond1 {
| do_stuff()
| }
| do_other_stuff()
| }

which can be rewritten like

| switch {
| case cond1:
| do_stuff()
| fallthrough
| case cond2:
| do_other_stuff()
| }

It's not quite visible due to cond* being short, but not so when they
involve comparisons against longish symbols exported from packages.

[Doğan Kurt]

In first snippet, i didn't get the second if. cond1 is true anyway.

Second snippet is equivalent to 

if (cond1) {

    do_stuff() 

    do_other_stuff() 

} else if cond2 {

    do_other_stuff() 

}

which is more straightforward than using fallthrough imo.

[Fumi Takeuchi]

Thanks a lot for your polite and convenient replies.

This time, I decided to use nested if-else instead of switch-fallthrough.

As all of you mentioned, I have to avoid this. Maybe it's not Go style.

What I actually want to write is very little router that determines which to provide converted file or raw file.

I want to use `http.FileServer` and `http.Dir` to provide raw file server and 404 responder because of its security advantages.

Thank you.

2017年8月1日火曜日 21時35分00秒 UTC+9 Fumi Takeuchi:

[T L]

On Tuesday, August 1, 2017 at 8:41:21 AM UTC-4, Jan Mercl wrote:

On Tue, Aug 1, 2017 at 2:34 PM Fumi Takeuchi <fmodqu...@gmail.com> wrote:

> Example code: https://play.golang.org/p/dVtPVt3oKt
>
> Maybe `fallthrough` statement cannot be used in `if` block even if it's put inside `swicth` block)

True: It may be used only as the final non-empty statement in such a clause.

why to make this restriction?

And why to make the similar restriction for goto:

https://golang.org/ref/spec#Goto_statements
"A "goto" statement outside a block cannot jump to a label inside that block"

 

[Doğan Kurt]

Fallthrough must be a design choice but goto's restriction is a necessity. 

What happens if you jump into the middle of an if block? You skipped the condition check, you run the code after the goto label, what about the code before the label, there might be some variables initialized, and how will you use this variables if you skip the initialization code.

Same applies to loops, furthermore, which iteration are you gonna be in?

[T L]

On Friday, August 4, 2017 at 6:59:41 PM UTC-4, Doğan Kurt wrote:

Fallthrough must be a design choice but goto's restriction is a necessity. 

What happens if you jump into the middle of an if block? You skipped the condition check, you run the code after the goto label, what about the code before the label, there might be some variables initialized, and how will you use this variables if you skip the initialization code.

Same applies to loops, furthermore, which iteration are you gonna be in?

Compiler can detect whether or not some undeclared variables will be used

package main

func main() {
    goto L // error: goto L jumps over declaration of i
   
    var i int
    _ = i
   
L:
    println("not use i any more")
}

 

[judson...@google.com]

> Maybe `fallthrough` statement cannot be used in `if` block even if it's put inside `swicth` block)

True: It may be used only as the final non-empty statement in such a clause.

> why to make this restriction?

One reason is that an excessively long case statement could hide a control flow modification high up in the code that invisibly modifies the behavior at the end of the case.