5 ms·

> It doesn't add things, it takes them away, notably exceptions, inheritance, generics. s/exceptions/error handling/ What Go proposes is awful for a modern la

• weberc2 9y ago
  Go has error handling, it doesn't have exceptions for non-exceptional error cases.
  • wasted_intel 9y ago
    Go has functions with multiple return values. That's not at all the same.
    • weberc2 9y ago
      I didn't talk about multiple return values, did I? Every language has error handling support, some languages hijack an exception mechanism as a control flow path for non-exceptional error states. Returning error values is more ergonomic than exceptions, but Go's lack of sum types makes this slightly tedious (still better than exceptions).
      • wasted_intel 9y ago
        Right, I jumped ahead; multiple return values is the how Go returns error values, it's not error handling itself. I don't like exceptions much either, but sum types / ADTs are just so nice for this sort of thing.
        • weberc2 9y ago
          I agree that sum types are nicer, but I don't see how they constitute error handling in a way other return mechanisms do not. The difference isn't categorical, it's ergonomic.
  • hasenj 9y ago
    I'm starting to find it weird that things like "error while passing string as int" trigger an exception rather than return an error. There are always error cases to check when handling user input. It's a natural part of the program flow, not really an exception. I would expect an 'exception' to be something like out of memory or disk corruption.
    • weberc2 9y ago
      Presumably you mean "user provided a string which was supposed to be decodable as an int, but was not"? If so, then yes, this should be handled as an input error and not as an exception (programmer error). I don't know if you meant this as a criticism of Go or not, but you should find that Go programs almost always return errors (as opposed to panicking) under such circumstances.