I might have sort of agreed if recover() didn’t exist. Since it does exist, panic(), it’s essentially a design where exceptions do exist, but you cannot differentiate between them, and you can also use them with goroutines.
I also agree that signalling errors in the return values is usually a better approach, but Go also got the Either a b/'a, 'b result type laughably wrong. In the design where product types exist but sum types and destructuring don’t, nothing keeps you from just ignoring the possibility of an error and using the alleged return value in an expression.
If you are given a Maybe or Either type, you have to explicitly handle the case when the callee gives you an error value instead of a result.
And then, practical implementations of algebraic effects seem like a matter of time now.
I think you need recover() to scope “it’s game over man” to something that makes more sense; for example the current goroutine or current HTTP request. In those scenarios, completely bringing down a server with a panic() doesn’t strike me as desirable, but completely bringing down the current connection or goroutine does.
Unfortunately this does allow for the possibility of abuse and using panic() as poor man’s exceptions – something not uncommon for new Go programmers more used to exception-based languages (I did this myself) – but that’s not the intended use. I’m not sure if there’s any way around this?
Oh, I’m not against having a mechanism for signalling a failure from goroutines (there has to be some). My point is that, at the language level, goroutines that are expected to cause recoverable panics are indistinguishable from those that aren’t supposed to panic at all or should always be treated like fatal errors if they do.
It’s the same problem as now knowing whether a function throws exceptions or not, viewed from a slightly different angle. If you want your program to decide what to do with panicking goroutines (retry/abort/ignore ;), you’ll end up replicating either exceptions or sum types in a compiler-unenforceable way.
Fair enough. I’ve actually made the mistake by not scoping panics() a few times, and making a more explicit choice about this would probably be better. In practice, I’ve actually found that most – although obviously not all – panics() should actually be scoped to the goroutine.
What’s a valid reason to panic in a HTTP handler?
Most of my experience has been with poorly written dependencies that panic, which I now tend to avoid.
But I also can’t really recall choosing to panic in a web server in code I’ve written.
In general: you probably shouldn’t. But you don’t always control panics: they may happen due to nil dereference, accessing an array beyond its size, etc. In practice, it’s pretty hard to give a hard guarantee that any given non-trivial Go code will never panic.
That is intentional and useful. If the same error has different consequences when called by different callers, the error value should be ignored. However, when writing idiomatic Go, you generally return a zero value result for most error scenarios.
Assigning _ to an error (or ignoring the return values altogether) is definitely something that could be trivially caught with a linter.
I still think it’s a mistake to allow both to coexist. In this case, you need an additional tool to catch something. Whereas with proper sum types, it is simply not possible to access a return value if you get an error. What you do with that is up to you.
val, err := foo()
if err != nil { /* log and carry on, or ignore it altogether */ }
bar(val) // <- nothing prevent you from doing that, and it very likely a mistake
Another case of “Go should have been SML + channels”, really. That would have been as simple, cleaner, and less error prone. But what can you expect from people who think the only flaw of C is that it doesn’t have a GC…
That’s so obvious that I forgot about it. I don’t know of any modern language that doesn’t have a (bound-checked) array type. On the other hand they decided to keep null nil…
You have to keep in mind that C is most certainly not a modern language & they were intentionally starting with C & changing only what they felt would add a lot of value without adding complexity.
It’s rather an anti-pattern rather than “pattern” (for example static analysis will mark this as a warning). Also, the e Exception should be Exception e.
RuntimeExceptions & errors are like panics (well-written code should never throw them at runtime) while regular exceptions are something that you have to handle (like Go’s return types) and something you can’t anticipate (e.g. I/O exception during file reads cannot be avoided by defensive programming).
I might have sort of agreed if
recover()didn’t exist. Since it does exist,panic(), it’s essentially a design where exceptions do exist, but you cannot differentiate between them, and you can also use them with goroutines.I also agree that signalling errors in the return values is usually a better approach, but Go also got the
Either a b/'a, 'b resulttype laughably wrong. In the design where product types exist but sum types and destructuring don’t, nothing keeps you from just ignoring the possibility of an error and using the alleged return value in an expression. If you are given aMaybeorEithertype, you have to explicitly handle the case when the callee gives you an error value instead of a result.And then, practical implementations of algebraic effects seem like a matter of time now.
I think you need recover() to scope “it’s game over man” to something that makes more sense; for example the current goroutine or current HTTP request. In those scenarios, completely bringing down a server with a panic() doesn’t strike me as desirable, but completely bringing down the current connection or goroutine does.
Unfortunately this does allow for the possibility of abuse and using panic() as poor man’s exceptions – something not uncommon for new Go programmers more used to exception-based languages (I did this myself) – but that’s not the intended use. I’m not sure if there’s any way around this?
Oh, I’m not against having a mechanism for signalling a failure from goroutines (there has to be some). My point is that, at the language level, goroutines that are expected to cause recoverable panics are indistinguishable from those that aren’t supposed to panic at all or should always be treated like fatal errors if they do.
It’s the same problem as now knowing whether a function throws exceptions or not, viewed from a slightly different angle. If you want your program to decide what to do with panicking goroutines (retry/abort/ignore ;), you’ll end up replicating either exceptions or sum types in a compiler-unenforceable way.
Fair enough. I’ve actually made the mistake by not scoping panics() a few times, and making a more explicit choice about this would probably be better. In practice, I’ve actually found that most – although obviously not all – panics() should actually be scoped to the goroutine.
What’s a valid reason to panic in a HTTP handler? Most of my experience has been with poorly written dependencies that panic, which I now tend to avoid. But I also can’t really recall choosing to panic in a web server in code I’ve written.
In general: you probably shouldn’t. But you don’t always control panics: they may happen due to nil dereference, accessing an array beyond its size, etc. In practice, it’s pretty hard to give a hard guarantee that any given non-trivial Go code will never panic.
The idea is that the server shouldn’t die just because one request triggered a panic.
Hm, a language that uses product types instead of sum types to represent “result or error” is certainly not doing exceptions right.
Exactly
You can still use the returned value and ignore the error. I’m not calling that “right”
That is intentional and useful. If the same error has different consequences when called by different callers, the error value should be ignored. However, when writing idiomatic Go, you generally return a zero value result for most error scenarios.
Assigning
_to an error (or ignoring the return values altogether) is definitely something that could be trivially caught with a linter.I still think it’s a mistake to allow both to coexist. In this case, you need an additional tool to catch something. Whereas with proper sum types, it is simply not possible to access a return value if you get an error. What you do with that is up to you.
Thought the same. It gets this right:
And here it goes wrong:
Another case of “Go should have been SML + channels”, really. That would have been as simple, cleaner, and less error prone. But what can you expect from people who think the only flaw of C is that it doesn’t have a GC…
Not just GC but also bounds checking.
That’s so obvious that I forgot about it. I don’t know of any modern language that doesn’t have a (bound-checked) array type. On the other hand they decided to keep
nullnil…You have to keep in mind that C is most certainly not a modern language & they were intentionally starting with C & changing only what they felt would add a lot of value without adding complexity.
For sure, I just don’t get why anyone would want that. 🤷 I guess.
Primarily linguistic simplicity in the service of making code easier to read.
Website is down :(
Probably
paniced.It is up for me at time of writing, but in any case here’s an archive.today mirror.
It’s rather an anti-pattern rather than “pattern” (for example static analysis will mark this as a warning). Also, the
e Exceptionshould beException e.RuntimeExceptions & errors are like panics (well-written code should never throw them at runtime) while regular exceptions are something that you have to handle (like Go’s return types) and something you can’t anticipate (e.g. I/O exception during file reads cannot be avoided by defensive programming).