On Wed, Mar 2, 2016 at 3:14 PM, Tapio Raevaara wrote:
The point is that a case with an operation on a nil channel will never be
selected, and that wouldn't change if nil channel operations would panic
outside of select. Which is why I don't see how blocking *instead of
panicking* on nil channel operation is in any way "useful".
That's not how panic works; panic is for things that should _never_
happen (eg. it's like an assert in other languages). It's a way to
fail fast if something catastrophically bad happens (eg. code that's
impossible to hit is hit because someone screwed something up, a
critical error that could lead to a security compromise happened,
etc.). If something were to panic in a select case, we wouldn't want
it to magically recover the panic and not select that case, we'd still
want to know about it.

You're right, the language could have used panic differently and made
reads from nil channels panic and had select catch them, but it
wouldn't be the same language. This was a deliberate choice to make
things like the example I made possible without magically covering up
serious errors.

TL;DR — I think you're thinking that panic is used for something it
wasn't designed for; blocking is much cleaner.


Sam Whited
pub 4096R/54083AE104EA7AD3

You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts


Follow ups

Related Discussions



site design / logo © 2022 Grokbase