Why I’m not leaving Python for Go

Post by barrkel » Mon, Sep 24, 2012, 1:54 AM UTC

Post by barrkel » Mon, Sep 24, 2012, 2:03 AM UTC

to3m wrote: post #61

jimbokun wrote: post #49

Earlier quoted context omitted.

"Of course, you can add more code to deal individually with each of the exceptions in more robust ways, even to the point of wrapping each statement in its own try/catch block, but then it's no different in practice from returning error codes." It is very different. With a try/catch block, you can see the normal logic flow of your code in one place, separated from the error handling logic. If you wrap each and every…

Um... errors ARE normal operation. Consult historical output from your C++ compiler, if you don't believe me! (If anything, that should probably be "errors", quotes included, because what people usually mean by the term is "easily-forseeable occurrence that I couldn't be bothered to write the code for".)

Post by anacrolix » Mon, Sep 24, 2012, 2:04 AM UTC

0xABADC0DA wrote: post #38

d0m wrote: post #28

Earlier quoted context omitted.

That's his whole point. He doesn't want to ignore errors but feels like Go is so verbose about it that it's a pain for programmers to deal with it. Example in case, print . Would you check its return value every time you call it? No. Contrast that to other languages, such as python, where you don't ignore the errors because you know that if something goes wrong, an exception will be raised. It lets you do stuff like:…

It's actually worse than that. The blog has error handling code like: if err := datastore.Get(c, key, record); err != nil { return &appError{err, "Record not found", 404} } This is pretty typical Google Go error handling, where errors are only actually used as boolean flags. Errors are universally returned as type 'error' so to actually do anything with the error you have to first cast it to some specific type. But t…

Post by hasenj » Mon, Sep 24, 2012, 2:14 AM UTC

0xABADC0DA wrote: post #38

d0m wrote: post #28

Earlier quoted context omitted.

That's his whole point. He doesn't want to ignore errors but feels like Go is so verbose about it that it's a pain for programmers to deal with it. Example in case, print . Would you check its return value every time you call it? No. Contrast that to other languages, such as python, where you don't ignore the errors because you know that if something goes wrong, an exception will be raised. It lets you do stuff like:…

It's actually worse than that. The blog has error handling code like: if err := datastore.Get(c, key, record); err != nil { return &appError{err, "Record not found", 404} } This is pretty typical Google Go error handling, where errors are only actually used as boolean flags. Errors are universally returned as type 'error' so to actually do anything with the error you have to first cast it to some specific type. But t…

    switch err.(type) {
       case Type1: 
          // do something
       case Type2:
          // something different
       default: 
          // something else
    }

Post by dchest » Mon, Sep 24, 2012, 2:43 AM UTC

azth wrote: post #72

TazeTSchnitzel wrote: post #2

I'll agree that this is perhaps the single thing that I don't like about Go. Now, you can argue it helps with "explicit error handling" and all that, but in that case you might as well have must-be-caught exceptions. Anyone want to fork Go?

If anything, they should have used sum types instead of product types to handle errors.

  x, err := something()
  if err != nil {
      handleError(err)
  }
  n, err := somethingElse(x)
  if err != nil {
      handleError(err)
  }
  andSoOn()

  switch x := something() {
  case error:
     handleError(err)
  case string:
     switch n := somethingElse(x) {
       case error:
         handleError(n)
       case int:
         andSoOn()
     }
  }

?