> With Go making errors a return value you have to actively discard the result (by replacing it with a underscore, e.g. `res, _ := getResults()`) or take the time to handle the error.

Right, but because `err` ends up getting re-used in so many cases, you can re-assign it and forget to do anything about it (which is what I've found in most cases where an error was inappropriately suppressed in Go).

In most cases, simply bubbling up the error to something that will generically handle all errors is the right thing to do, and in the case of exceptions, even if you don't know about one, that is what will happen. I just sampled a handful of the top Golang repos on Github, and found very few cases of anything more than the standard `if err != nil; return nil, err' pattern that just bubbles the error up.

Last time I wrote go you could write `doThingAndMaybeReturnErr()` without the `_ =`. Has this changed?

The alternative is Zig or Rust's thing, where you still have explicit error handling but you don't repeat the same four lines all the time. This is maybe helpful because in Go one has to read those lines carefully to see if anything unexpected is happening.

> Since Go makes errors a return value you have to actively discard the result (by replacing it with a underscore, e.g. `res, _ := getResults()`) or take the time to handle the error.

LoadData(&data)

Does this function return nothing or an error ?

> Since Go makes errors a return value you have to actively discard the result (by replacing it with a underscore, e.g. `res, _ := getResults()`) or take the time to handle the error.

This is a bad thing because it’s not narrow. It’s like a language’s “catch” statement not allowing you to catch specific exceptions. Once someone has decided to throw away an error with the underscore assignment, all future errors the underlying might return are swallowed as well.

In other words, it takes even more boilerplate to have narrower error exemptions than to have the generic exemption.

> It seems to me that the result is more errors are properly handled in Go - because they are explicit - while uncaught exceptions often cause bugs that make it to production.

An error in go that is blindly returned all of the way up the stack has no difference with an uncaught exception.

This is great in theory but in reality no such distinction exists. For example, is trying to read a missing file a failure of the code, or a failure of the user? It could easily be either, the developer hardcoded the file path wrong during development, or the user selected a wrong path in a CLI, ... the distinction between errors and exceptions must made by the call site, not the definition site. The code calling readFile() knows whether the error is recoverable or not. readFile() itself does not, so the same mechanism should be used for both errors and exceptions.

All this was figured out decades ago, that's why exception systems were invented, but language designers keep making the same mistake over and over again in an effort to simplify the unsimplifiable.

Your entire argument rests on the weird assumption that the User is responsible for the environment. In the vast majority of software used today, that is not the case.

In SaaS, mobile, and appliances, the environment is entirely or almost entirely controlled by the programmer - a missing file is the developer's problem, and the user can't do anything about it.

In enterprise software, there is a third entity, the Administrator, that has (almost) full control over the environment, and usually there are layers of 3rd party software that control it directly. A missing file or permission error is useless to the user, most likely it needs to be logged somewhere that Admins check, and the user simply told to contact their Admin.

Finally, even in personal desktop software, the environment is jointly owned by the user and the developer - the developer is normally responsible for setting up the initial environment through some kind of installer (msi, deb, make configure etc.), and many environment issues are bugs in the installer, not user errors.

Of course, the same library may very well be used in all of these vastly disparate deployment scenarios - the library can't decide what is the source of an error, so making it arbitrarily decide between two possible kinds of errors is wrong.

Note that even the reverse is not clear; an index out of bounds error could be a user problem - if they are trying to access the 7th element of a 5 element list. The fact that you'd normally do

  if userSelectedElement > len(arr) {
    return nil, fmt.Errorf("Array index out of bounds")
  }
  return arr[userSelectedElement], nil

Is only because of the convention you were proposing - `return arr[userSelectedElement]` does the same thing alone, if we disregard the convention (in a memory safe language, of course!).

>Exceptions are for the former, which Go still supports via Panic().

The panics are there to be used only in cases where the further code execution is impossible. Not to inform the developer about an error.

Errors are a general solution to report an unexpected event during execution. The destination of such report depends on the part of code the program failed.

I've never had a Java IDE insert something like that?

But either way, you have to go out of your way to do that, which is sort of my point.

The one place where you do see dumb boilerplate and chances to screw up is in dealing with checked exceptions, which have been controversial since the very beginning. I think they are one of those things that seem like a great idea in theory, but end up not working out so well in practice, but (like people who appreciate Go's error handling model) there are people who disagree.

The proposal for better error handling was rejected, as far as I'm aware. Generics needlessly repeated the mistakes of Java and C# in coming out years too late.

Then you just have Railroad Programming without the monadic binding operators and currying of the languages where that is the main mode of dealing with errors. That sounds awful.

The whole point of Exceptions is to avoid writing try/catch all over the place. Let's take an example of idiomatic exception-based code:

  func doRequests(url1, url2 string) resp throws HttpException {
    resp1 := http.DoRequest("POST", url1)
    resp2 := http.DoRequest("GET", url2 + resp1.ID)
    return resp2
  }

vs

  func doRequests(url1, url2 string) (resp, error) {
    resp1, err := http.DoRequest("POST", url1)
    if err != nil {
      return nil, fmt.Errorf("Error in req1: %w", err)
    }
    resp2, err := http.DoRequest("GET", url2 + resp1.ID)
    if err != nil {
      return nil, fmt.Errorf("Error in req2: %w", err)
    }
    return resp2, nil
  }

Of course, we can write the second example with try/catch as well, but the whole point of exceptions is to be able to write the first one when appropriate.

Yep - my biggest gripe is seeing errors with no context around them - either a stack trace or...well...the context.Context.

The thing I hate about table-driven tests is that they make it slightly harder to identify where an error has occurred, and much harder to debug the specific test case that triggered the error, especially in Go where dlv lacks value breakpoints (or it did last time I checked - if they've added that in the meantime, this becomes much less of a problem).

Well that's why I said as far as I know. What else has something similar?