4 ms·

Honestly, it's not the 2-4-8 indentation or the placement of braces that gets me when reading code. In Go, my biggest problem is that there are so many x, err

• sagichmal 12y ago
  > I get lost trying to figure what > the happy path behavior is. The happy path is idiomatically at indent level 0.
  • azth 12y ago
    Except when it's if x, err := doSomething(); err != nil { }
    • sagichmal 12y ago
      ...the happy path there is intend level 0? if err := doSomething(); err != nil { return fmt.Errorf("something failed: %v", err) } Or, x, err := doSomething() if err != nil { return fmt.Errorf("something failed: %v", err) } log.Print(x)
• acdha 12y ago
  I'm hoping Go's error handling is improved in 2.0. I understand the objections to Java-style exceptions but I think they underestimated the actual cost of having so much boilerplate clogging up every non-trivial program, not to mention the way it actively encourages people to punt on error checking which is why so many projects are littered with `x, _ := foo()`. The approach I'd like would be a lightweight assert-style failure mode where the compiler would treat any function which returns an error as being followed an implied `if err != nil { panic("Unhandled error") }` unless the error is checked on the next statement. That'd allow you to handle things which you expect to fail regularly while preventing the litany of bugs in C programs caused by forgetting to check return codes on things which rarely fail.