[goldinfra]

Sounds like you may be confused thinking that a panic in Go is like throw in other languages? Third-party libraries should virtually never panic. Go has panic, and it's useful for a few things, but does not use them as exceptions are used in other languages.

This is a bit like worrying that your programming language won't prevent a third-party library from sending a SIGKILL to your program or that it doesn't prevent third-party libraries from delete your entire file system.

No general purpose language protects against malicious or stupid code.

[jamescostian]

I've seen apps break in prod where third party libraries had array accesses on indices that didn't exist, or dereferenced nil pointers, in goroutines they spawned. And those aren't the only ways to cause a panic without ever calling the panic function.

Third party libraries have bugs sometimes, and other times our usage of them can create bugs. Nothing like a SIGKILL or anything malicious. That's just the way things are and will be. And breaking down like this in dev can be fantastic!

But when a once in a blue moon issue crops up in prod and all other connections are dropped, the fact that a simple defer+recover couldn't have been preemptively placed on all goroutines is a huge nightmare. I'd even take a "you can add defer+recover for any goroutines created further in this callstack" - it's rare that libraries spawn goroutines, I'll already know which ones to trigger that behavior on

[beltsazar]

> But when a once in a blue moon issue crops up in prod and all other connections are dropped, the fact that a simple defer+recover couldn't have been preemptively placed on their goroutines is a huge nightmare

Yeah, this is one of the weird things, to say it mildly, that Go does that is hardly mentioned anywhere. Most people don't know about it until they themselves first encounter the nightmare bug similar to what you said.

[goldinfra]

Wrapping every third-party library in defensive code doesn't make a lot of sense since this isn't the most dangerous kind of bug. To make a one example of a million: a third-party database library that corrupts your database is infinitely more dangerous and that there's no form of wrapping that will save you.

Bad code is bad code. Bugs are bugs. This issue is not a major source of problems in Go code.

[beltsazar]

> Sounds like you may be confused thinking that a panic in Go is like throw in other languages?

Not at all. I knew that panics in Go shouldn't be used for error handling in general.

> Third-party libraries should virtually never panic.

True, as true as 3rd-party libraries shouldn't have any security vulnerabilities. But we don't live in a perfect world. Bugs happen.

> This is a bit like worrying that your programming language won't prevent a third-party library from sending a SIGKILL to your program or that it doesn't prevent third-party libraries from delete your entire file system.

Very different. Your examples are intentional and malicious actions. What usually happens is due to bugs.

> No general purpose language protects against malicious or stupid code.

Are you implying that all bugs are caused by either malicious code or stupid code? Panic-related bugs are often due to the billion dollar mistake [1] that Go's team refused to solve.

---

[1] https://www.infoq.com/presentations/Null-References-The-Bill...

[mbivert]

> but does not use them as exceptions are used in other languages

IIRC, the Go lexer/parser itself relies on panic/recover to handle errors[0], in an exception-like fashion. Granted, it's one unusual case, where the code is split in a multitude of mutually recursive functions.

[0]: https://github.com/golang/go/blob/master/src/go/parser/parse...