-
-
Save iamatypeofwalrus/84b6c7d946a6a4143a1d to your computer and use it in GitHub Desktop.
// An intersting pattern for testing, but you can use the check anywhere | |
import "testing" | |
func TestCheckingChannel(t *testing.T) { | |
stop := make(chan bool) | |
// Testing some fucntion that SHOULD close the channel | |
func (stop chan bool) { | |
close(chan) | |
}(stop) | |
// Make sure that the function does close the channel | |
_, ok := (<-stop) | |
// If we can recieve on the channel then it is NOT closed | |
if ok { | |
t.Error("Channel is not closed") | |
} | |
} |
why not to use atomic.Bool?
I have to admit that I didn't understand all of your code in the playground, but it seems more complex and slower. It also doesn't do what the original intent of this gist is: which I interpret as reading from a channel in a non-blocking way.
General remark: I don't think it's a good idea to overload the built-in close
function (the only way to close a channel).
@noamnelke I have never heard about overload in Go. the close
func in this gist is just a Closer
implementation
I didn't understand all of your code
so sad
The error will never occur. If the channel isn't closed the function will block forever on line 13.
It would work if you replaced line 13 with the following:
ok := true select { case _, ok = <-stop: default: }A
select
with adefault
clause is a non-blocking read from the channel.
Thanks , you save my day.
❤️
👍🏻