Go supports panic/recover which is very similar to exceptions. Instead of wrapping a try...catch block around something, you get to handle exceptions every time they are about to cause a function to be exited.
This means you can't continue to execute the function, but you do get a chance of handling the exception / turning it into a regular return value.
tl;dr: Go has exceptions, they are just a little different (IMO for the better).
Panic and recover are non-idiomatic; using them the way you would exceptions in Python is (stylewise, I mean) a little like using setjmp and longjmp for flow control in a C progam.
In the Go standard library source code, "panic" has pretty much the role 'assert(!"error message")' has in C.
The reality is that Go does not have exceptions the way Python does. If you're writing idiomatic Go, you're manually checking errors.
> In the Go standard library source code, "panic" has pretty much the role 'assert(!"error message")' has in C.
Well, there's no real way to recover after such an assert (the C stdlib is undefined when you catch the SIGABRT, the stack is not guaranteed to be big enough to do anything, most I/O is not guaranteed to work, etc. -- really, very few uses for catching a SIGABRT). There is a way in Go, even if it is far less capable than your average "except .." clause in C++.
> The reality is that Go does not have exceptions the way Python does.
True. Some of us (e.g. me) think that's a big advantage. (I'm not implying you disagree - I don't know what your opinion is)
I'm not a fan of the lack of exceptions in Go, but it's not a dealbreaker for me. I feel like Go code is very cluttered and fussy. I don't love the language as a language. But as a tool for getting systems programming problems solved, it is pretty amazing, and I love working with it.
I think the real value of panic/recover over try/catch is the vastly improved idiomatic usage. Only to be used in exceptional cases, and never to cross package boundaries.
Hmmm, interesting. The "defer" approach is a different spin on things. But yes, panic/recover does look like it would address my concerns. I never did like exceptions across package boundaries much, but inside a cohesive module I want to use them instead of a bunch of code that checks return values for error codes.
This means you can't continue to execute the function, but you do get a chance of handling the exception / turning it into a regular return value.
tl;dr: Go has exceptions, they are just a little different (IMO for the better).