Hacker News Reader

Comment by Mawr | Hacker News Reader

You're reading way too much into what the parent poster said. He just correctly stated the overall sentiment of the community.

That said, suggesting adding exceptions to Go is about as reasonable as adding a GC to Zig. How much effort would you spend arguing against someone bringing that up as a serious proposal?

View on HN

> 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.

Go doesn't use exceptions as a primary way of handling errors, which is what we're talking about here. Pedantry is not welcome.

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.

Your pedantry is hilarious and contradictory.

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.

That's a lot of pedantry you've got there for someone who claims it is not welcome. Rules for thee, not for me?

But, if you'd kindly come back to the topic at hand:

> That is what the discussion here is about - the way errors are handled in a language in practice, not in theory.

While I'm not entirely convinced that is accurate, I will accept it. Now, how does:

- "That said, suggesting adding exceptions to Go is about as reasonable as adding a GC to Zig."

Relate to that assertion? What does "suggesting adding exceptions to Go" have to do with a common pattern that has emerged?

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.

Okay, but how does that relate to what was said?

You’re just complaining because the compiler isn’t complaining

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.

Dude you tried, there’s no need for 50000 word essay against a sentence

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?

    "spherical cow in a vacuum"

I only learned about this recently. Very funny to me, and appropriately used here. Ref: https://en.wikipedia.org/wiki/Spherical_cow

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.

You can get pretty close with generics:

    func Must[Value any](v Value, err error) Value {
        if err != nil {
            panic(err)
        }
        return v
    }

    Must(strconv.Atoi("not a number"))

(https://go.dev/play/p/NnrZ30TflDI)

;)

> 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,

    func GetUser() (*User, error) {
        return nil, ErrNotFound
    }

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.

What's the alternative?

    func GetUser() (*User, error) {
        return &User{
            Name:  "No User",
            Email: "not@found.com",
            Role:  DoesNotExist,
        }, ErrNotFound
    }

Why on earth would you do that?

> 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.

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.

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

You would crash the process. But, sometimes it's useful to do a little bookkeeping first.

That's not how recover is used in practice

Right. In practice, people don't even realize that Go has an exception handling system (see rest of thread) to use.

Reply on news.ycombinator.com