go: proposal: Go 2: local-only throw-catch error handling

To me the examples in the proposal are overwhelmingly more confusing than the traditional alternative.

Playing around with some demo client code I wrote, I think I prefer the following:

1. Using the keyword ‘or’ to trigger an exception when err != nil.
2. Using the keyword ‘catch’ to name an exception handler.
3. Allowing the use of ‘throw’ in the code body to delegate to an exception handler.

Here’s some code illustrating how we can use exception names to clearly name the errors inline while still moving lengthy, distracting error descriptions to the end of the function. It should suffice for the compile to just do macro-expansion.

const (
	loginURL   = "https://some.source.com/context/login/"
	refererURL = "https://some.source.com/"
	apiURL     = "https://some.source.com/api/specify/"
)

type collectionsJSON struct {
	Collections map[string]int `json:"collections"`
}

type loginJSON struct {
	UserName   string `json:"username"`
	Password   string `json:"password"`
	Collection int    `json:"collection"`
}

type Connection struct {
	CsrfToken string
	Referer   string // (sic)
	Cookies   []*http.Cookie
}

func Connect(collectionName, username, password string) (*Connection, error) {

	// Visit login page to get the CSRF token and collection ID

	req, !err := http.NewRequest("GET", loginURL, nil) or noInitialRequest
	res, !err := http.DefaultClient.Do(req) or noInitialPage
	var csrfToken string
	cookies := res.Cookies()
	for _, c := range cookies {
		if c.Name == "csrftoken" {
			csrfToken = c.Value
			break
		}
	}
	if csrfToken == "" {
		throw noCsrfToken
	}

	body, !err := ioutil.ReadAll(res.Body) or noInitialPageBody
	defer res.Body.Close()
	var result collectionsJSON
	!err = json.Unmarshal(body, &result) or failedParsingInitialBody
	collections := result.Collections
	var collectionID int
	foundCollection := false
	for name, id := range collections {
		if name == collectionName {
			collectionID = id
			foundCollection = true
			break
		}
	}
	if !foundCollection {
		throw collectionNotFound
	}

	// Login

	loginInfo := loginJSON{
		UserName:   username,
		Password:   password,
		Collection: collectionID,
	}
	loginInfoJSON, !err := json.Marshal(loginInfo) or failedParsingLogin
	req, !err = http.NewRequest("PUT", loginURL, bytes.NewBuffer(loginInfoJSON))
		or noLoginRequest
	req.Header.Set("Content-Type", "application/json")
	req.Header.Set("X-CSRFToken", csrfToken)
	req.Header.Set("Referer", refererURL)
	for _, cookie := range cookies {
		req.AddCookie(cookie)
	}
	res, !err = http.DefaultClient.Do(req) or noLoginResponse
	if res.StatusCode < 200 || res.StatusCode >= 300 {
		throw failedLogin
	}
	body, !err = ioutil.ReadAll(res.Body) or failedParsingLoginBody
	defer res.Body.Close()
	cookies = res.Cookies()

	return &Connection{
		CsrfToken: csrfToken,
		Referer:   refererURL,
		Cookies:   cookies,
	}, nil

	// Handle exceptions

	catch noInitialRequest {
		return nil, fmt.Errorf("failed to create login page request: %v", err)
	}
	catch noInitialPage {
		return nil, fmt.Errorf("failed to receive login page response: %v", err)
	}
	catch noCsrfToken {
		return nil, fmt.Errorf("did not receive a CSRF token")
	}
	catch noInitialPageBody {
		return nil, fmt.Errorf("failed to read login page body: %v", err)
	}
	catch failedParsingInitialBody {
		return nil, fmt.Errorf("failed to unmarshall [%s]: %v", body, err)
	}
	catch collectionNotFound {
		return nil, fmt.Errorf("failed to find collection \"%s\" in %v",
			collectionName, collections)
	}
	catch failedParsingLogin {
		return nil, fmt.Errorf("failed to marshal login info: %v", err)
	}
	catch noLoginRequest {
		return nil, fmt.Errorf("failed to create auth request: %v", err)
	}
	catch noLoginResponse {
		return nil, fmt.Errorf("failed to receive auth response: %v", err)
	}
	catch throwFailedLogin {
		return nil, fmt.Errorf("login failed with status code %d", res.StatusCode)
	}
	catch failedParsingLoginBody {
		return nil, fmt.Errorf("failed to read auth body: %v", err)
	}
}

Or perhaps we disagree as to what self-documenting code looks like.

My suggestion. catch runs first then catcher is called:

func CopyFile(src, dst string) error {
    r := os.Open(src)   catch
    defer r.Close()
    w := os.Create(dst) catch
    _ := io.Copy(w, r)  catch { w.Close(); os.Remove(dst) }
    w.Close()           catch { os.Remove(dst) }

    catcher (err error) {
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }
}

Could even pass arguments to the catcher:

func CopyFile(src, dst string) error {
    r := os.Open(src)   catch ("open src")
    defer r.Close()
    w := os.Create(dst) catch ("create dst")
    _ := io.Copy(w, r)  catch ("copy src to dst") { w.Close(); os.Remove(dst) }
    w.Close()           catch ("close dst") { os.Remove(dst) }

    catcher (msg string, err error) {
        return fmt.Errorf("%s error: %v", msg, err)
    }
}

I removed !err cause I dont like it and it could be suppressed. But if you’d rather put it back, ok.

Edit:

Another option:

func CopyFile(src, dst string) error {
    r := os.Open(src)   catch
    defer r.Close()
    w := os.Create(dst) catch
    io.Copy(w, r)       catch { w.Close(); os.Remove(dst) }
    w.Close()           catch { os.Remove(dst) }
    return nil
} catch (err error) {
    return fmt.Errorf("copy %s %s: %v", src, dst, err)
}

Or yet:

func CopyFile(src, dst string) error {
    r := os.Open(src)   catch
    defer r.Close()
    w := os.Create(dst) catch
    io.Copy(w, r)       catch { w.Close(); os.Remove(dst) }
    w.Close()           catch { os.Remove(dst) }
    return nil
catch (err error):
    return fmt.Errorf("copy %s %s: %v", src, dst, err)
}

For the record, it wouldn’t be a “goto” due to closure requirements. As explained above, this would best be implemented as macro expansion.

In any case, I find several aspects of Go at odds with writing self-documenting code:

• The requirement to mix error handling with the primary code path obfuscates the purpose of the code.
• Using capitalization to indicate scope inclines people to use abbreviations for instances of classes.
• Placing the error return at the front of each call adds just a little bit of effort to scanning for the function called.
• Requiring the target to appear at the front of each definition requires us to scan right to find the function name.

My experience with this thread suggests that the community in general does not value self-documenting code.

I don’t know that I’ve seen a strong preference for keeping error handling with the main code path as such. I’ve seen a strong preference for simplicity and clarity.

With this proposal, I’m inclined toward @carlmjohnson 's comment at https://github.com/golang/go/issues/48896#issuecomment-940573338. You’ve written trap and catch but the construct is not a trap or catch as used in most languages, because it does not work across functions. It’s a goto label. So why not use goto?

Back when the discussions for error handling were lively, there was a proposal to improve goto, so it could handle cases like this. (At present, goto won’t let you goto a section of code where new variables have been declared.) This is very similar to those proposals. The effect ends up looking like Ruby, in which methods end with a rescue block.

Having read through all those debates, the conclusion I came to is that there’s not really any way to improve Go’s error handling besides just adding if err? as a shortcut for if err == nil and return ..., err as a placeholder for whatever the other return values are. Any other improvement either ends up being two ways to write the same thing or makes it easier to write code without wrapping errors, neither of which is desirable. In this case, the error handling is the same, but shunted off to the end, which I guess is okay, but it’s not clear why having it all at the end is that much better than having it all inline.

Heck, the catch (or trap) code blocks could actually be macro-expanded where exceptions are thrown (or traps are triggered), eliminating the need to treat them as closures.