1. 12
  1.  

  2. 9

    I’m still flabbergasted that the Go community just goes in and builds stacktraces by hand while claiming it is a superior way to do things.

    No other mainstream language I can think of (aside from C) has, as a main mechanism to handle errors, a concept by which a function may return both the good ‘ok’ value and the bad ‘err’ value, and both can be used at once within a code block. Any option type-based or exception-based flow will let you return either of these values, but never both at once. It’s not error handling, it’s a convention over multiple return values.

    And if it were only either of these it wouldn’t be too bad, but now you’re stuck hand-assembling stacktraces under some of the worst error-handling semantics imaginable since a thread-global ERRNO variable. To add insult to injury, none of the go-2 proposals seemed to address any of the semantics, only the syntax.

    That’s without mentioning the terrible conversion from a panic to a return value, which must be done through a defer that suddenly relies on re-binding named variable within the function signature and may force to re-structure the whole caller’s existing error handling.

    I’ve been following Go since day 1, and used it professionally for a good while, and I still can’t understand why anyone subjects themselves to such shitty design when it comes to critical features such as error management.

    1. 9

      It’s easier to comprehend Go as effectively not having error handling at all in the core language. Instead, error-handling conventions are required. I think that it goes back to the machismo that Go’s authors have carried with them since the days of C; in their minds, it is not only not problematic to not have error-handling subsystems, but superior since additional effort is constantly expended, and constant expenditure of additional effort is extremely macho.

      1. 2

        anyone subjects themselves to such shitty design

        because you can’t win them all in life.

      2. 1

        Personally, I find the API needlessly confusing.

        I was really hoping he’d write the rest of what he was probably thinking here. My guess is that it went something like:

        , but because the Go authors didn’t listen to the community about adopting one of the emerging libraries (e.g. pkg/errors), we have yet another example of “shut up and eat this,” instead.

        1. 6

          The core team has made it pretty clear what their operating and governance philosophies are, and I burned a lot of energy on the dependency management fiasco, so I think I’m done tilting at those windmills. But I can expand on what I found confusing.

          Most importantly, I expect a Wrap function, especially because the presence of Unwrap is confusing without it. I’ve heard the technical reasons for omitting it, but I don’t find them convincing; there are ways around it.

          Also, the Is and As functions don’t clearly communicate their purpose. As in particular seems like a function to create or transform an error, rather than to inspect one. Maybe that’s on me.

          1. 1

            Most importantly, I expect a Wrap function, especially because the presence of Unwrap

            Right. The “interface” for interacting with this is odd. I think the magic of using format strings, and the fact that there is 100+ lines of code to deal with preprocessing the format strings is a sign there’s a simpler alternative.

            Also, the Is and As functions don’t clearly communicate their purpose.

            I find Is acceptable, though it implies type equivalence to me, not that the error is wrapped in the chain. Has, or Contains might be better, but it seems like there’s an attempt at an illusion that an error in the chain makes it that type. It’s kind of a weird position, to me.

            As seems a casualty of Go’s type system not being able to return a dynamic concrete type, so, :shrug:, I guess.