Go Replaces Interface{} with 'Any'

Post by dragonwriter » Tue, Dec 14, 2021, 11:19 PM UTC

randomdata wrote: post #139

linkdd wrote: post #88

Earlier quoted context omitted.

An exception has a stacktrace. This single piece of information is crucial when you debug and makes handling errors in Golang embarrassing. I rest my case.

Go exceptions do carry stack trace information. However, the topic is errors, not exceptions. Those are very different concepts. Of what use is stack trace information in debugging values that you have assigned error meaning to when not other types of values? If you had a function func add(a, b int) int { return a * b } there would be no expectation of carrying a stack trace to debug it. So what's different about fun…

Post by maximus-decimus » Tue, Dec 14, 2021, 11:21 PM UTC

Groxx wrote: post #124

13415 wrote: post #93

Earlier quoted context omitted.

It makes no sense to replace a meaningful and helpful criterion - whether it breaks code or not - by some purely subjective assessment of what's a "major change." That just leads to usual version creep, from "Go 2.2" to "Go 3.0", to "Go 4.0", to (inevitable) "Go 10", "Go 11", "Go 11 Pro", "Go 11 Ultimate Edition",...

It could be worse, they could start naming these "Go WXGA+", "Go i99900kf", and "Go for Women".

Post by rp1 » Tue, Dec 14, 2021, 11:27 PM UTC

linkdd wrote: post #130

rp1 wrote: post #128

Earlier quoted context omitted.

I’ve been doing a lot of rust programming recently, but how exactly is the Result monad better? I feel like I end up with nested match statements for chained results, but maybe I’m doing something wrong.

Rely more on the map/map_err/or_else/... methods for the Result type. You'll get something like (pseudocode): may_fail_who_knows() .map(use_value) .map_err(some_error_processing) .and_then(another_computation_which_can_fail) .or_else(with_some_error_handling_that_can_rescue) .unwrap_or(a_default_value) Basically, instead of nested match expressions, you get a "pipeline".

Post by linkdd » Tue, Dec 14, 2021, 11:30 PM UTC

randomdata wrote: post #139

linkdd wrote: post #88

Earlier quoted context omitted.

An exception has a stacktrace. This single piece of information is crucial when you debug and makes handling errors in Golang embarrassing. I rest my case.

Go exceptions do carry stack trace information. However, the topic is errors, not exceptions. Those are very different concepts. Of what use is stack trace information in debugging values that you have assigned error meaning to when not other types of values? If you had a function func add(a, b int) int { return a * b } there would be no expectation of carrying a stack trace to debug it. So what's different about fun…

  func read_file(filename string) (string, error) {
    return "", errors.New("oops")
  }

  func foo() error {
    a, err := read_file("a.txt")
    if err != nil {
        return errors.New(fmt.Sprintf("read a: %s", err))
    }

    b, err := read_file("b.txt")
    if err != nil {
        return errors.New(fmt.Sprintf("read b: %s", err))
    }

    // do stuff with a and b
    return nil
  }

  func main() {
    err := foo()
    if err != nil {
      fmt.Fprintln(os.Stderr, err)
    }
  }

  func read_file(filename string) string {
    throw FileNotFound(filename)
  }

  func foo() {
    a := read_file("a.txt")
    b := read_file("b.txt")
    // do stuff with a and b
  }

  func main() {
    try {
      foo()
    }
    catch (err FileNotFound) {
      fmt.Fprintf(os.Stderr, "file not found: %s\n%s\n", err.filename, err.Stacktrace())
    }
  }

Post by randomdata » Tue, Dec 14, 2021, 11:34 PM UTC

linkdd wrote: post #147

randomdata wrote: post #139

Earlier quoted context omitted.

Go exceptions do carry stack trace information. However, the topic is errors, not exceptions. Those are very different concepts. Of what use is stack trace information in debugging values that you have assigned error meaning to when not other types of values? If you had a function func add(a, b int) int { return a * b } there would be no expectation of carrying a stack trace to debug it. So what's different about fun…

Current state of the art: func read_file(filename string) (string, error) { return "", errors.New("oops") } func foo() error { a, err := read_file("a.txt") if err != nil { return errors.New(fmt.Sprintf("read a: %s", err)) } b, err := read_file("b.txt") if err != nil { return errors.New(fmt.Sprintf("read b: %s", err)) } // do stuff with a and b return nil } func main() { err := foo() if err != nil { fmt.Fprintln(os.St…

  func read_file(filename string) string {
    panic(FileNotFound{filename})
  }

  func foo() {
    a := read_file("a.txt")
    b := read_file("b.txt")
    // do stuff with a and b
  }

  func main() {
    defer func() {
      if err, ok := recover().(FileNotFound); ok {
        fmt.Fprintf(os.Stderr, "file not found: %s\n%s\n", err.filename, err.Stacktrace())
      }
    }

    foo()
  }