re: Go 2 Draft: Error Handling VIEW POST

VIEW PARENT COMMENT VIEW FULL DISCUSSION

To answer your questions -

  1. The handle blocks chain. Once an handle block is reached, it becomes part of the chain. If an error occurs, the blocks execute from the bottommost block to the topmost. (It is proposed to remove the chaining functionality, though)

  2. If you simply want to add functionality, just add another handle block when you want that functionality to start being used. (Like the file-copy example I have in the post). Otherwise you'll have to do the standard if err != nil

  3. There's a few reasons behind this:

a. It's easier to think about needing to "declare" your handle blocks. You can't use a handle block if it hasn't been declared yet!

b. It makes for much faster compile times to require handle blocks.

c. It makes it more similar to how defer works (if you don't know Go this doesn't mean much)

d. Enabling a handle block to be after a check block means that the handle block may have more variables in it's scope than what was at the check block...


// Demonstrates why `handle` must be above `check`
func ErrorTesting() {
    check errors.New("some kind of error") // will go to handle block

    i := 5
    handle err {
        log.Fatalf("i=%d, err=%v", i, err)
        // Since we got here from the top line, i has not been declared!
    }
}

Thanks for your elaborate reply.

Maybe I shouldn’t do this, but in my head I compare this to the try/catch/finally concept. Catch comes after try but cannot use any variables that have not been declared before try. But it makes the flow much clearer since you usually read code from top to bottom.
And one of my questions was how to implement multiple catch blocks. With try/catch i can have muktiple of those constructs or even multiple catch blocks. Let’s say I have file operation and a parsing operation and I want to handle them differently, I could declare two different catch blocks. How would I do this with check/handle?

It would look something like this:

In current Go with the handle construct would look something like this:

handle err {

    if notExist, ok := err.(*os.ErrNotExist); ok {
        // Do stuff with notExist
    } else if otherErr, ok := err.(*pack.OtherErr); ok {
        // Do stuff with otherErr
    }
}

// Or if your list is very long
handle err {
    switch err.(type) {
    case *os.ErrNotExist:
        // Code...
    case ...:
        // ...
    default:
        // ...
    }
}

Note that the notExist, ok := err.(*os.ErrNotExist) is how you typecast in Go. Also, a semicolon in an if statement means "just execute the left side normally and evaluate the right side as the condition", although any variables declared on the left side have block scope within the if statement.

Errors in Go are just an interface, so you just cast them to the error that you want to check.

code of conduct - report abuse