> That said, suggesting adding exceptions to Go is about as reasonable as adding a GC to Zig.
Suggesting the addition of exceptions to Go is as reasonable as suggesting the addition of loops to Rust. Which is to say that it already has exceptions, and always has. Much of the language's design is heavily dependent on the presence of exceptions.
Idioms dictate that you probably shouldn't use exceptions for errors (nor should you in any language, to be fair), but even that's not strictly adhered to. encoding/json in the standard library famously propagates errors using the exception handlers.
It doesn't not use exception handlers as a primary way of handling errors either, though. Go doesn't specify any error handling mechanism. Using exception handlers is just as valid as any other, and even the standard library does it, as noted earlier.
The only error-related concept the Go language has is the error type, but it comes with no handling semantics. Which stands to reason as there is nothing special about errors. Originally, Go didn't even have an error type, but it was added as a workaround to deal with the language not supporting cyclic imports.
You're absolutely technically correct, in the "spherical cow in a vacuum" sense. In reality though, essentially all Go code out there handles errors through the pattern of checking if the error in a `(value, error)` tuple returned from a function is `nil` or not. That is what the discussion here is about - the way errors are handled in a language in practice, not in theory. Therefore, pedantry.
Basically, discussions have context and I have no intention of prepending 10 disclaimers to every statement I make to preemptively guard against people interpreting my comments as absolutes in a vacuum.
It’s not simply a common pattern. It is a way of doing things in the community. The stdlib uses it, the libraries use it, and if you do not use it, people will not use your software.
And you're panicking because the other commenters haven't helped recover for you. Try as you might, sadly they are not here to catch you. No need to throw a fit over it. You are not as exceptional as you think you are.
The output of software cares not for whether it be a sentence or even just a word. The output of software has no care at all. What lead you to believe otherwise?
The problem with go exceptions (panics) is that they are a second class citizen. Leading to ignorance of using “defer”-statement when needed, opening up risk of leaving mutexes and other critical handlers open.
I would be happy if they would add in compiler some thing that'll allow to ignore error return values and in this case compiler would just throw exception^Wpanic from that point. I think it even makes sense for go purists, like you need to handle errors or get panicked. And I'd just mostly ignore errors and will have my sweet exceptions.
> I think it even makes sense for go purists, like you need to handle errors or get panicked.
You think wrong. Go preaches that zero values should be useful, with means in the common (T, error) scenario, T should always be useful even if there is also an error state. Worst case, you will get the zero value in return, which is still useful. This means that the caller should not need to think about the error unless it is somehow significant to the specific problem they face. They are not dependent variables.
I understand where you are coming from as in other languages it would be catastrophic to ignore errors, but that's not how Go is designed. You cannot think of it like you do other languages, for better or worse.
> T should always be useful even if there is also an error state.
I disagree with this blanket assertion. In a limited set of cases would I ever expect a result to be valid if there was also an error.
Also, when you disagree with what someone thinks, there are different ways to respond and using "You think wrong" is probably one of the most confrontational ways of responding.
> In a limited set of cases would I ever expect a result to be valid if there was also an error.
You have to return something for T. Go does not allow you to return nothing. Why would you return garbage when you can just as easily return the zero value, that of which should always be useful? Yes, you technically could return garbage, but why? There is absolutely no justification. Consider,
Here, T is useful. You don't necessarily need to look at error in this example. You can meaningfully work with T alone if the error state is insignificant to your specific use case.
> Also, when you disagree with what someone thinks, there are different ways to respond and using "You think wrong" is probably one of the most confrontational ways of responding.
Imagine thinking that the output of software is being confrontational or exhibiting of any kind of output that congers this kind of change in "emotional state". As nonsensical as the random number generator outputting three consecutive 6s and then concluding that it must be the work of the devil. So strange.
Then it shouldn't have added exceptions in the first place. But exceptions in go exist and so does exception (un)safety, and denial only leads to buggy code. I cannot count how many times I've seen exception unsafe code in go exactly because everyone keeps ignoring them
What would you use when you actually have an exception, then? Exception and exception handlers are a useful construct, but, like everything else, become problematic when used outside of their intended purpose.
Just because exception and error both start with the letter "e" does not mean they are in any way related. They have very different meanings and purposes.
If they are really exceptional situations that should never happen, just crash the process. The moment recover was added they become just another error handling mechanism
Suggesting the addition of exceptions to Go is as reasonable as suggesting the addition of loops to Rust. Which is to say that it already has exceptions, and always has. Much of the language's design is heavily dependent on the presence of exceptions.
Idioms dictate that you probably shouldn't use exceptions for errors (nor should you in any language, to be fair), but even that's not strictly adhered to. encoding/json in the standard library famously propagates errors using the exception handlers.