What do I do if I encounter panic when I operate the channel?

This is a creation in Article, where the information may have evolved or changed.

Many students in the use of the channel has encountered this situation: panic problem, I believe that the design also spit out a lot of it? In this article we'll take a piece of the original purpose of this design.

There are two main types of potential panic: Repeat close one channel and continue sending messages to the already closed channel.

The most lazy solution is to use the recover to simple rough recovery, but this is against the designer's original intention. For Channel C, the built-in close function indicates that no more values will be sent to C, repeated shutdowns, or sending any messages to the closed C will result in runtime panic, and closing the nil channel also causes panic.

Here's a question: what happens if C is turned off and you continue reading messages from C? Don't worry, at least no panic will happen. The first is to read from C before the message sent but not received, when such a message is received, and then received the message is the corresponding channel type 0 value, note that the message from a closed channel is not blocked at all!! Of course, we can determine whether the channel has been closed by the second parameter of the receive operation, and if it shuts down, do not continue to receive the message.

Back to the recover topic above, why not propose to do so, because once you do that, it means that you are not aware of any potential bugs in your programming, but only think about the most brutal way of dealing with exception handling. Sending a message to a channel that is still open is a possible bug! of design

In fact, from the bottom, close is also a message on the channel send operation, but send a special shutdown message, the message is committed to the system, the channel will never receive any more messages. If you continue to send messages, you will violate this commitment. Also, because close is a message sent, repeating close also causes panic.

Everyone should know this idiom: The channel should only be closed by the sender. The students must also have doubts, if the same channel has multiple senders? This is the problem of our programming, if multiple senders are asked to close the channel, but there is no communication between them, it is problematic: because of this situation, if a sender to close the channel, but do not notify other senders, there is a large potential bug, At least close a public channel, need to get everyone's approval!

Here is a copy of the original version of Rob Pike's great god:

Closing a channel is a matter of releasing a resource. Closing a channel multiple times is like closing a file descriptor multiple times, freeing chunks of memory multiple times without meaning. These actions all mean that the code is problematic, which is why we have forced the panic to design.

Look, the great God is a great God, a word on the clear problem: are design and code problems! So it's very important to make your own design and code clear, so you don't have to solve the problem without recover.

In short, Go's design principle is concise, clear, not redundant, with a popular phrase: My code, I am the master!