This is definitely not the current state of the art. Errors are values with types just like anything else in the language; dynamically populating calls to errors.New() is super weird (the point of errors.New is mostly to create global errors you can compare against), your errors nest without using %w, and there are a bunch of simple libraries that wrap typed stack traces in errors, just like there are a bunch of simple libraries in Rust that exist to make error types compatible with each other.

Your "state of the art" Go code is not really a good example of how that functionality would be written.

If you want to check for a specific error condition, then just define a value for that error and use `errors.Is` to check for it. This works as you'd expect with wrapping: https://go.dev/play/p/rJIlKKSYn9Q

> With the current go error handling, you need to add the informations yourself in the string, not as a real data structure.

This is completely false! If you want to provide a structured error, then you just need to define a type for it. In your example, a Go programmer might use errors.Is(err, fs.ErrNotExist) and errors.As if they wanted to retrieve the specific file path that does not exist in a strongly-typed way, something like https://go.dev/play/p/hdHPLAVbQuW.

> Delegating error handling to a try/catch block with a typed data structure allows the caller to care for certain type of errors and delegate the others to its own caller. With the current error type in Go, what would you do? parse the error message?

Certainly not! I think there is a misconception that "an error is a string" -- in Go, an error is actually any type that satisfies the error interface, i.e. has an `Error() string` method. It can be any type at all, and have as many other methods as you like in order to provide the functionality you need.

> what if the function is defined in a dependency you have no control over?

There's nothing stopping you from writing `throw new Exception(String.format("file not found: %s", filename))` in languages with exceptions either. In both cases, it would be recognized as poor API design.

Regarding stack traces, Go makes a strong distinction between errors (generally a deviation from the happy path) and panics (a true programming error, e.g. nil pointer dereference, where the program must exit). Errors do not provide stack traces since there is no need for them in a flow control context, panics do provide stack traces for useful debugging information.

Your code is wrong. It would normally be written something like this:

  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()
  }

However, exceptions are meant for exceptional circumstances (hence the name), not errors. A file error is not exceptional in the slightest. It is very much expected.

While you can overload exceptions to pass errors (or any other value), that does not mean you should. Your use of exceptions for flow control (i.e. goto) is considered harmful.