For some context here's another error handler in Google Go:

    defer func() {
        if r := recover(); r != nil {
            if err, ok := r.(runtime.Error); ok {
                if err.String() == "runtime error: index out of range" {
                    // handle bad index
                    return
                }
            }

            panic(r)
        }
    }()

vs

    try {
    }
    catch (IndexOutOfBoundsException ex) {
        // handle bad index
    }

A language where you have to resort to string compare to handle invalid array accesses can't be use as a model for good error handling IMO.

Of course that's just the tip of an iceberg with no way for IDEs/tools to know what return is an error, no way to know at a glance if "_" was an ignored error or ignored other extra return value, plus other fundamental problems caused by implicit types.