Declined Proposal: A built-in Go error check function, “try”

Post by didibus » Wed, Jul 17, 2019, 5:30 AM UTC

dnautics wrote: post #183

poweroftrue wrote: post #168

Just try writing three Go programs with error handling, then, try other languages! I was pissed at first. However, now I cannot code in any language without overusing try and being scared of each line. Using Go's error handling is actually making your code smarter, I mean, you don't want your code to break with a weird message because of something stupid. The simplest example is adding a default-path whenever I'm rea…

try errors in elixir: with {:ok, val1} handle_notfound_error() {:error, :eperm} -> report_permission_error() _ -> raise("don't worry this process is supervised, let it crash!") end low cyclomatic complexity makes for a nice user experience, and you learn the philosophy of "if it doesn't work, just turn it off and on again". Why be scared? Just let it go. The VM has your back.

  try {
    var val1 = happy_path1(val0);
    var val2 = happy_path2(val0, val1);
    var val3 = happy_path3(some_val);
    function_might_crash_let_it_crash!(some_val);
    return happy_result();
  } catch (NotFoundError e) {
    handle_notfound_error();
  } catch (PermissionError e) {
    report_permission_error();
  } catch (Exception e) {
    throw new Exception("don't worry this process is supervised, let it crash!");
  }

Post by meddlepal » Wed, Jul 17, 2019, 5:32 AM UTC

geodel wrote: post #159

KirinDave wrote: post #102

Earlier quoted context omitted.

> It is the single worst thing in Java for me. Checked exceptions add nothing and break almost everything around clean design & code. Should I compare it to "Golang Dependency Hell Claimed My Project?" > For that comparison to work, java would have needed to only have checked exceptions, with some added language features to deal with them cleanly, and then it might actually have been a viable design. Why? That's not…

> Should I compare it to "Golang Dependency Hell Claimed My Project?" Of course you can. But it would be hilarious considering Java Module system (Jigsaw) which took decade in making still does not support versioning. People are left to use bloated crap like Maven or Gradle. But since these products are called "enterprise grade" developers are not supposed to call them crap that they really are.

Post by voidfunc » Wed, Jul 17, 2019, 5:35 AM UTC

diminoten wrote: post #186

KirinDave wrote: post #45

Earlier quoted context omitted.

> Do I particularly like managing errors that way? No, but I do think that it improves the transparency and quality of a lot of Go projects. So long as we can all agree that it feels super bad, I guess this is fine. But it does sort of mean that Golang approaches the Java world back with checked exceptions where principle trumped ergonomics. That lead to a world where folks felt "forced" to use Java, and that's a sti…

Yeah but as a prospective Go user, the fact that the language is opting for pain turns me off. Enjoy your ecosystem, I'm going to continue to use languages that actually like me, and care how my experience is.

Post by meddlepal » Wed, Jul 17, 2019, 5:43 AM UTC

sagichmal wrote: post #223

millstone wrote: post #206

Earlier quoted context omitted.

Disagree hard! a = append(a[:i], a[i+1:]...) That’s the recommended implementation of erase(). After this, is the original object referred to by ‘a’ modified? How can you tell? Let’s pop from a stack: x, a = a[len(a)-1], a[:len(a)-1] Did you read that 100x faster than ‘a.pop()’? Now this: a = append(a[:i], append(make([]T, j), a[i:]...)...) This is an operation called “expand.” What does it do? It is an honest questi…

Slice operations are deliberately verbose in this way so as not to hide the cost of allocation that goes along with them. They are not common in code, but they do make good strawmen when you want to counter general points with specific ones.

Post by qtplatypus » Wed, Jul 17, 2019, 5:51 AM UTC

bmurphy1976 wrote: post #169

qtplatypus wrote: post #162

Earlier quoted context omitted.

Its a pity that they listened to the members of the community that was opposed to try. I was a massive fan of try or anything else that would prevent me writing the same boilerplate code. I feel some in the go community have become convinced that the “go way” is to write the same code over and over again.

I think try is jumping the gun. Implementing try now is splitting the community and introducing what will likely be new technical debt. It doesn't fundamentally change things, it only makes the language more complicated in a way that's both weird* and likely to become obsolete once generics are a thing. They should focus on xerrors for now and wait until generics are implemented and try again. * weird as in there are…