Why does Go panic on writing to a closed channel?
From the Go Language Spec:
For a channel c, the built-in function close(c) records that no more values will be sent on the channel. It is an error if c is a receive-only channel. Sending to or closing a closed channel causes a run-time panic. Closing the nil channel also causes a run-time panic. After calling close, and after any previously sent values have been received, receive operations will return the zero value for the channel's type without blocking. The multi-valued receive operation returns a received value along with an indication of whether the channel is closed.
If you write to a closed channel, your program will panic. You could potentially catch this error with recover if you really want to do that, but being in a situation where you don't know whether the channel you are writing to is open is usually a sign of a bug in the program.
Some quotes:
Here is a motivation:
A channel "close" is really just a send of a special value on a channel. It is a special value that promises that no more values will be sent. Attempting to send a value on a channel after it has been closed will panic, since actually sending the value would violate the guarantee provided by close. Since a close is just a special kind of send, it is also not permitted after the channel has been closed.
Here is another:
The only use of channel close is to signal to the reader that there are no more values to come. That only makes sense when there is a single source of values, or when multiple sources coordinate. There is no reasonable program in which multiple goroutines close a channel without communicating. That would imply that multiple goroutines would know that there are no more values to send--how could they determine that if they don't communicate?
(Ian Lance Taylor)
--
Here is another:
Closing a channel releases it as a resource. It makes no more sense to close a channel multiple times than it makes to close a file descriptor multiple times, or free a block of allocated memory multiple times. Such actions imply the code is broken, which is why closing a closed channel triggers a panic.
(Rob Pike)
--
Source: Go design detail rationale question - channel close
Everton
SRE since 2016. Network engineer for 20+ years. Enjoy computer engineering in general. Find lots of fun in the Go Programming Language.
Updated on January 28, 2020Comments
-
Everton over 4 years
Why does Go panic on writing to a closed channel?
While one can use the
value, ok := <-channel
idiom for reading from channels, and thus the ok result can be tested for hitting a closed channel:// reading from closed channel package main import "fmt" func main() { ch := make(chan int, 1) ch <- 2 close(ch) read(ch) read(ch) read(ch) } func read(ch <-chan int) { i,ok := <- ch if !ok { fmt.Printf("channel is closed\n") return } fmt.Printf("read %d from channel\n", i) }
Output:
read 2 from channel channel is closed channel is closed
Run "reading from closed channel" on Playground
Writing to a possibly closed channel is more convoluted, because Go will panic if you simply try to write when the channel is closed:
//writing to closed channel package main import ( "fmt" ) func main() { output := make(chan int, 1) // create channel write(output, 2) close(output) // close channel write(output, 3) write(output, 4) } // how to write on possibly closed channel func write(out chan int, i int) (err error) { defer func() { // recover from panic caused by writing to a closed channel if r := recover(); r != nil { err = fmt.Errorf("%v", r) fmt.Printf("write: error writing %d on channel: %v\n", i, err) return } fmt.Printf("write: wrote %d on channel\n", i) }() out <- i // write on possibly closed channel return err }
Output:
write: wrote 2 on channel write: error writing 3 on channel: send on closed channel write: error writing 4 on channel: send on closed channel
Run "writing to closed channel" on Playground
As far as I know, there is not a simpler idiom for writing into a possibly closed channel without panicking. Why not? What is the reasoning behind such an asymmetric behavior between read and write?