Nesting function calls in GO

Let us say we want to implement following computation:

outval / err = f3(f3(f1(inval))

where each of f1, f2, f3 can fail with an error at that time we stop the computation and set err to error returned by the failing function. (Of course, nesting can be arbitrarily long)

In languages like C++/JAVA/C# it can be easily done by having f1, f2 and f3 throw an exception and enclosing the computation in a try-catch block, while in languages like Haskell we can use monads instead.

Now I am trying to implement it in GO and the only approach I can think of is obvious if-else ladder which is rather verbose. I don't have issue if we can't nest the calls, but in my opinion adding error check after each line in code looks ugly and it breaks the flow. I would like to know if there is any better way of doing it.

Edit: Editing as per the comment by peterSO
Below is the concrete example and straightforward implementation

package main

import "fmt"

func f1(in int) (out int, err error) {
    return in + 1, err
}

func f2(in int) (out int, err error) {
    return in + 2, err
}

func f3(in int) (out int, err error) {
    return in + 3, err
}

func calc(in int) (out int, err error) {
    var temp1, temp2 int
    temp1, err = f1(in)
    if err != nil {
        return temp1, err
    }
    temp2, err = f2(temp1)
    if err != nil {
        return temp2, err
    }
    return f3(temp2)
}

func main() {
     inval := 0
     outval, err := calc3(inval)
     fmt.Println(inval, outval, err)
}

What I am trying to illustrate is, function calc does some computation possibly with the help of library functions that can fail and semantics is if any call fails calc propagates the error to the caller (similar to not handling the exception). In my opinion, code for calc is ugly.

Between for this particular case where all library functions have exactly same signature, we can make the code better (I am using idea from http://golang.org/doc/articles/wiki/#tmp_269)

func saferun(f func (int) (int, error)) func (int, error) (int, error) {
    return func (in int, err error) (int, error) {
        if err != nil {
            return in, err
        }
        return f(in)
    }
} 

Then we can redefine calc as

func calc(in int) (out int, err error) {
    return saferun(f3)(saferun(f2)(f1(in)))
}

or as

func calc(in int) (out int, err error) {
    sf2 := saferun(f2)
    sf3 := saferun(f3)
    return sf3(sf2(f1(in)))
}

But without generics support, I am not sure how I can use this approach for any set of library functions.

If you really want to be able to do this you could use a compose function.

func compose(fs ...func(Value) (OutVal, error)) func(Value) (OutVal, error) {
  return func(val Value) OutVal, Error {
    sVal := val
    var err error
    for _, f := range fs {
      sval, err = f(val)
      if err != nil {
        // bail here and return the val
        return nil, err
      }
    }
    return sval, nil
  }
}

outVal, err := compose(f1, f2)(inVal)

Most of the time though you probably want to be more straightforward than this since it may be difficult for others to understand your code when they encounter it.

First, an expanded version of the try-catch style that you are used to, borrowing obviously from jimt's answer and PeterSO's answer.

package main

import "fmt"

// Some dummy library functions with different signatures.
// Per idiomatic Go, they return error values if they have a problem.
func f1(in string) (out int, err error) {
    return len(in), err
}

func f2(in int) (out int, err error) {
    return in + 1, err
}

func f3(in int) (out float64, err error) {
    return float64(in) + .5, err
}

func main() {
    inval := "one"

    // calc3 three is the function you want to call that does a computation
    // involving f1, f2, and f3 and returns any error that crops up.
    outval, err := calc3(inval)

    fmt.Println("inval: ", inval)
    fmt.Println("outval:", outval)
    fmt.Println("err:   ", err)
}

func calc3(in string) (out float64, err error) {
    // Ignore the following big comment and the deferred function for a moment,
    // skip to the comment on the return statement, the last line of calc3...
    defer func() {
        // After viewing what the fXp function do, this function can make
        // sense.  As a deferred function it runs whenever calc3 returns--
        // whether a panic has happened or not.
        //
        // It first calls recover.  If no panic has happened, recover returns
        // nil and calc3 is allowed to return normally.
        //
        // Otherwise it does a type assertion (the value.(type) syntax)
        // to make sure that x is of type error and to get the actual error
        // value.
        //
        // It does a tricky thing then. The deferred function, being a
        // function literal, is a closure.  Specifically, it has access to
        // calc3's return value "err" and can force calc3 to return an error.
        // A line simply saying  "err = xErr" would be enough, but we can
        // do better by annotating the error (something specific from f1,
        // f2, or f3) with the context in which it occurred (calc3).
        // It allows calc3 to return then, with this descriptive error.
        //
        // If x is somehow non-nil and yet not an error value that we are
        // expecting, we re-panic with this value, effectively passing it on
        // to allow a higer level function to catch it.
        if x := recover(); x != nil {
            if xErr, ok := x.(error); ok {
                err = fmt.Errorf("calc3 error: %v", xErr)
                return
            }
            panic(x)
        }
    }()
    // ... this is the way you want to write your code, without "breaking
    // the flow."
    return f3p(f2p(f1p(in))), nil
}

// So, notice that we wrote the computation in calc3 not with the original
// fX functions, but with fXp functions.  These are wrappers that catch
// any error and panic, removing the error from the function signature.
// Yes, you must write a wrapper for each library function you want to call.
// It's pretty easy though:
func f1p(in string) int {
    v, err := f1(in)
    if err != nil {
        panic(err)
    }
    return v
}

func f2p(in int) int {
    v, err := f2(in)
    if err != nil {
        panic(err)
    }
    return v
}

func f3p(in int) float64 {
    v, err := f3(in)
    if err != nil {
        panic(err)
    }
    return v
}
// Now that you've seen the wrappers that panic rather than returning errors,
// go back and look at the big comment in the deferred function in calc3.

So, you might protest that you asked for easier and this is not. No argument on the whole, but if the library functions all return error values and you want to chain function calls without the error values, the solution available is to wrap the library functions, and the wrappers are very thin and easy to write. The only other hard part is that deferred function, but it's a pattern that you can learn and reuse and it's only a few lines of code.

I don't want to promote this solution too much because it's not one that is used often. It is a valid pattern though, and does have some use cases where it is appropriate.

Error handling is a big subject, as jimt mentioned. "What are good ways to do error handling in Go?" would be a good question for SO except for the problem that it fails the "whole book" critereon. I can imagine a whole book on the subject of error handling in Go.

Instead, I'll offer my general observation that if you just start working with error values instead of trying to make them disappear, after a while you start understanding advantages of doing this. What looks like a verbose ladder of if statements in a toy example like we used here might still look like a verbose ladder of if statements when you first write it in a real world program. When you actually need to handle those errors though, you come back to the code and suddenly see it as stubs all waiting for you to flesh out with real error handling code. You can see just what to do because the code that caused the error is right there. You can sheild a user from seeing an obscure low level error message and instead show something meaningful. You as the programmer are prompted to do the right thing instead of accepting a default thing.

For more comprehensive answers, one good resource to start with is the article Error Handling and Go. If you search through the Go-Nuts messages there are long discussions on the matter there as well. The functions in the standard library call each other quite a bit, (surprise) and so the source code of the standard library contains many examples of handling errors. These are excelent examples to study since the code is written by Go authors who are promoting this programming style of working with error values.

The discussion between Errors vs Exceptions is a long and tedious one. I shall therefore not go into it.

The simplest answer to your question concerns Go's built-in defer, panic, and recover functions as discussed in this blog post. They can offer behaviour similar to exceptions.

package main

import "fmt"

func main() {
	defer func() {
		// This recovers from a panic if one occurred. 
		if x := recover(); x != nil {
			fmt.Printf("%v\n", x)
		}
	}()

	value := f(f(f(1)))
	fmt.Printf("%d\n", value)
}

func f(i int) int {
	value := i*i + 1

	// something goes wrong, panic instead of returning an error.
	panic("ohnoes")

	return value
}

Found mailing <a href="https://groups.google.com/forum/?fromgroups#!searchin/golang-nuts/generics/golang-nuts/W3tXPy-03JA/8H-foRw-QSgJ">thread</a> on go-nuts for this topic. Adding it for reference.

Without a concrete example, you are tilting at windmills. For example, per your definition, fn functions return a value and any error. The fn functions are package functions whose signature cannot be changed. Using your example,

package main

import "fmt"

func f1(in int) (out int, err error) {
	return in + 1, err
}

func f2(in int) (out int, err error) {
	return in + 2, err
}

func f3(in int) (out int, err error) {
	return in + 3, err
}

func main() {
	inval := 0
	outval, err := f3(f2(f1(inval)))
	fmt.Println(inval, outval, err)
}

How are you going to get your example to compile and run?

Too bad this one is closed already... This:

value := f(f(f(1)))

is not an example of chaining but of nesting. Chaining should look something like:

c.funA().funB().funC()

Here is a working example.