Golang return error from function

Error handling in Go is a little different than other mainstream programming languages like Java, JavaScript, or Python. Go’s built-in errors don’t contain stack traces, nor do they support conventional try/catch methods to handle them. Instead, errors in Go are just values returned by functions, and they can be treated in much the same way as any other datatype — leading to a surprisingly lightweight and simple design.

In this article, I’ll demonstrate the basics of handling errors in Go, as well as some simple strategies you can follow in your code to ensure your program is robust and easy to debug.

The Error Type

The error type in Go is implemented as the following interface:

type error interface {
    Error() string
}

So basically, an error is anything that implements the Error() method, which returns an error message as a string. It’s that simple!

Constructing Errors

Errors can be constructed on the fly using Go’s built-in errors or fmt packages. For example, the following function uses the errors package to return a new error with a static error message:

package main

import "errors"

func DoSomething() error {
    return errors.New("something didn't work")
}

Similarly, the fmt package can be used to add dynamic data to the error, such as an int, string, or another error. For example:

package main

import "fmt"

func Divide(a, b int) (int, error) {
    if b == 0 {
        return 0, fmt.Errorf("can't divide '%d' by zero", a)
    }
    return a / b, nil
}

Note that fmt.Errorf will prove extremely useful when used to wrap another error with the %w format verb — but I’ll get into more detail on that further down in the article.

There are a few other important things to note in the example above.

• Errors can be returned as nil, and in fact, it’s the default, or “zero”, value of on error in Go. This is important since checking if err != nil is the idiomatic way to determine if an error was encountered (replacing the try/catch statements you may be familiar with in other programming languages).

• Errors are typically returned as the last argument in a function. Hence in our example above, we return an int and an error, in that order.

• When we do return an error, the other arguments returned by the function are typically returned as their default “zero” value. A user of a function may expect that if a non-nil error is returned, then the other arguments returned are not relevant.

• Lastly, error messages are usually written in lower-case and don’t end in punctuation. Exceptions can be made though, for example when including a proper noun, a function name that begins with a capital letter, etc.

Defining Expected Errors

Another important technique in Go is defining expected Errors so they can be checked for explicitly in other parts of the code. This becomes useful when you need to execute a different branch of code if a certain kind of error is encountered.

Defining Sentinel Errors

Building on the Divide function from earlier, we can improve the error signaling by pre-defining a “Sentinel” error. Calling functions can explicitly check for this error using errors.Is:

package main

import (
    "errors"
    "fmt"
)

var ErrDivideByZero = errors.New("divide by zero")

func Divide(a, b int) (int, error) {
    if b == 0 {
        return 0, ErrDivideByZero
    }
    return a / b, nil
}

func main() {
    a, b := 10, 0
    result, err := Divide(a, b)
    if err != nil {
        switch {
        case errors.Is(err, ErrDivideByZero):
            fmt.Println("divide by zero error")
        default:
            fmt.Printf("unexpected division error: %sn", err)
        }
        return
    }

    fmt.Printf("%d / %d = %dn", a, b, result)
}

Defining Custom Error Types

Many error-handling use cases can be covered using the strategy above, however, there can be times when you might want a little more functionality. Perhaps you want an error to carry additional data fields, or maybe the error’s message should populate itself with dynamic values when it’s printed.

You can do that in Go by implementing custom errors type.

Below is a slight rework of the previous example. Notice the new type DivisionError, which implements the Error interface. We can make use of errors.As to check and convert from a standard error to our more specific DivisionError.

package main

import (
    "errors"
    "fmt"
)

type DivisionError struct {
    IntA int
    IntB int
    Msg  string
}

func (e *DivisionError) Error() string { 
    return e.Msg
}

func Divide(a, b int) (int, error) {
    if b == 0 {
        return 0, &DivisionError{
            Msg: fmt.Sprintf("cannot divide '%d' by zero", a),
            IntA: a, IntB: b,
        }
    }
    return a / b, nil
}

func main() {
    a, b := 10, 0
    result, err := Divide(a, b)
    if err != nil {
        var divErr *DivisionError
        switch {
        case errors.As(err, &divErr):
            fmt.Printf("%d / %d is not mathematically valid: %sn",
              divErr.IntA, divErr.IntB, divErr.Error())
        default:
            fmt.Printf("unexpected division error: %sn", err)
        }
        return
    }

    fmt.Printf("%d / %d = %dn", a, b, result)
}

Note: when necessary, you can also customize the behavior of the errors.Is and errors.As. See this Go.dev blog for an example.

Another note: errors.Is was added in Go 1.13 and is preferable over checking err == .... More on that below.

Wrapping Errors

In these examples so far, the errors have been created, returned, and handled with a single function call. In other words, the stack of functions involved in “bubbling” up the error is only a single level deep.

Often in real-world programs, there can be many more functions involved — from the function where the error is produced, to where it is eventually handled, and any number of additional functions in-between.

In Go 1.13, several new error APIs were introduced, including errors.Wrap and errors.Unwrap, which are useful in applying additional context to an error as it “bubbles up”, as well as checking for particular error types, regardless of how many times the error has been wrapped.

A bit of history: Before Go 1.13 was released in 2019, the standard library didn’t contain many APIs for working with errors — it was basically just errors.New and fmt.Errorf. As such, you may encounter legacy Go programs in the wild that do not implement some of the newer error APIs. Many legacy programs also used 3rd-party error libraries such as pkg/errors. Eventually, a formal proposal was documented in 2018, which suggested many of the features we see today in Go 1.13+.

The Old Way (Before Go 1.13)

It’s easy to see just how useful the new error APIs are in Go 1.13+ by looking at some examples where the old API was limiting.

Let’s consider a simple program that manages a database of users. In this program, we’ll have a few functions involved in the lifecycle of a database error.

For simplicity’s sake, let’s replace what would be a real database with an entirely “fake” database that we import from "example.com/fake/users/db".

Let’s also assume that this fake database already contains some functions for finding and updating user records. And that the user records are defined to be a struct that looks something like:

package db

type User struct {
  ID       string
  Username string
  Age      int
}

func FindUser(username string) (*User, error) { /* ... */ }
func SetUserAge(user *User, age int) error { /* ... */ }

Here’s our example program:

package main

import (
    "errors"
    "fmt"

    "example.com/fake/users/db"
)

func FindUser(username string) (*db.User, error) {
    return db.Find(username)
}

func SetUserAge(u *db.User, age int) error {
    return db.SetAge(u, age)
}

func FindAndSetUserAge(username string, age int) error {
  var user *User
  var err error

  user, err = FindUser(username)
  if err != nil {
      return err
  }

  if err = SetUserAge(user, age); err != nil {
      return err
  }

  return nil
}

func main() {
    if err := FindAndSetUserAge("bob@example.com", 21); err != nil {
        fmt.Println("failed finding or updating user: %s", err)
        return
    }

    fmt.Println("successfully updated user's age")
}

Now, what happens if one of our database operations fails with some malformed request error?

The error check in the main function should catch that and print something like this:

failed finding or updating user: malformed request

But which of the two database operations produced the error? Unfortunately, we don’t have enough information in our error log to know if it came from FindUser or SetUserAge.

Go 1.13 adds a simple way to add that information.

Errors Are Better Wrapped

The snippet below is refactored so that is uses fmt.Errorf with a %w verb to “wrap” errors as they “bubble up” through the other function calls. This adds the context needed so that it’s possible to deduce which of those database operations failed in the previous example.

package main

import (
    "errors"
    "fmt"

    "example.com/fake/users/db"
)

func FindUser(username string) (*db.User, error) {
    u, err := db.Find(username)
    if err != nil {
        return nil, fmt.Errorf("FindUser: failed executing db query: %w", err)
    }
    return u, nil
}

func SetUserAge(u *db.User, age int) error {
    if err := db.SetAge(u, age); err != nil {
      return fmt.Errorf("SetUserAge: failed executing db update: %w", err)
    }
}

func FindAndSetUserAge(username string, age int) error {
  var user *User
  var err error

  user, err = FindUser(username)
  if err != nil {
      return fmt.Errorf("FindAndSetUserAge: %w", err)
  }

  if err = SetUserAge(user, age); err != nil {
      return fmt.Errorf("FindAndSetUserAge: %w", err)
  }

  return nil
}

func main() {
    if err := FindAndSetUserAge("bob@example.com", 21); err != nil {
        fmt.Println("failed finding or updating user: %s", err)
        return
    }

    fmt.Println("successfully updated user's age")
}

If we re-run the program and encounter the same error, the log should print the following:

failed finding or updating user: FindAndSetUserAge: SetUserAge: failed executing db update: malformed request

Now our message contains enough information that we can see the problem originated in the db.SetUserAge function. Phew! That definitely saved us some time debugging!

If used correctly, error wrapping can provide additional context about the lineage of an error, in ways similar to a traditional stack-trace.

Wrapping also preserves the original error, which means errors.Is and errors.As continue to work, regardless of how many times an error has been wrapped. We can also call errors.Unwrap to return the previous error in the chain.

When To Wrap

Generally, it’s a good idea to wrap an error with at least the function’s name, every time you “bubble it up” — i.e. every time you receive the error from a function and want to continue returning it back up the function chain.

There are some exceptions to the rule, however, where wrapping an error may not be appropriate.

Since wrapping the error always preserves the original error messages, sometimes exposing those underlying issues might be a security, privacy, or even UX concern. In such situations, it could be worth handling the error and returning a new one, rather than wrapping it. This could be the case if you’re writing an open-source library or a REST API where you don’t want the underlying error message to be returned to the 3rd-party user.

Conclusion

That’s a wrap! In summary, here’s the gist of what was covered here:

• Errors in Go are just lightweight pieces of data that implement the Error interface
• Predefined errors will improve signaling, allowing us to check which error occurred
• Wrap errors to add enough context to trace through function calls (similar to a stack trace)

I hope you found this guide to effective error handling useful. If you’d like to learn more, I’ve attached some related articles I found interesting during my own journey to robust error handling in Go.

References

• Error handling and Go
• Go 1.13 Errors
• Go Error Doc
• Go By Example: Errors
• Go By Example: Panic

In this article, we shall be discussing how to return and handle errors effectively using custom and inbuilt Golang functions, with help of practical examples.

Golang return error

An error is basically a fault that occurs in a program execution flow. These errors can be of various natures:- Caused by programmers through code syntax and interface errors , system-related Resources and Runtime errors, algorithm-related logic and arithmetic errors. Which later are solved through debugging process.

In Golang ,The Error is an interface that holds Error() string method. Its implemented as follows

type error interface {
Error() string
}

In an nutshell, when the Error() method is called, it’s return value is in form of string datatype. Through the use of inbuilt Go functions of the fmt and errors packages, we can construct the kind of error message to be displayed. Below is an example to construct Errors using fmt.Error() in Golang, i.e you want to read a file from a given path, unfortunate the file doesn’t exist or the path given is invalid. For example:=

package main

import (
	"fmt"
	"os"
)

func ReadFile(file string) error {
	dataFile, err := os.ReadFile(file)
	if err != nil {
		return fmt.Errorf("An error occurred while Reading the file: open : %v", err)
	}
	fmt.Println(string(dataFile))
	return nil
}
func main() {
	resultsErr := ReadFile("")
	if resultsErr != nil {
		fmt.Printf("%v", resultsErr)
	}
}

Output:

ALSO READ: Golang check if key exists in map [SOLVED]

With the file attached ensure you replace the ReadFile(«test.txt»)

$ go run main.go
Hello

without file attached

$ go run main.go
An error occurred while Reading the file: open: no such file or directory

Explanation:- In the above code, ReadFile() error{} function returns an error which is nil whenever no error encountered. In Golang, the Error return value is nil as the default, or “zero”. Notice that checking if err != nil{} is the idiomatic way to determine if an error was encountered in Golang syntax, in this function we are returning the error only, handling the file data within the function. fmt.Error() enables us to customize the kind of message to be displayed. These messages are always in a lowercase format and don’t end with punctuation.

In Golang there are numerous ways to return and handle errors Namely:=

• Casting Errors
• Error wrapping mechanism
• Panic, defer and recover

Different methods of error handling in Go Func

Method 1:- Casting Errors

Casting errors is a way of defining custom and expected errors, with golang we can make use of erros.Isand errors.As() error functions to cast different types of errors. i.e,errors.Is we create a custom error of a particular type and check If the error matches the specific type the function will return true, if not it will return false.

package main

import (
	"errors"
	"fmt"
	"io/fs"
	"os"
)

var fileNotFound = errors.New("The file doesn't  exist")

func ReadFile(file string) error {
	dataFile, readErr := os.ReadFile(file)
	if readErr != nil {
		if errors.Is(readErr, fs.ErrNotExist) {
			return fmt.Errorf("this fileName %s  doesn't exist ", file)
		} else {
			return fmt.Errorf("Error  occured while opening the file : %w", readErr)
		}
	}
	fmt.Println(string(dataFile))
	return nil
}
func main() {
	fileName := os.Args[1]
	if fileName != "" {
		resultsError := ReadFile(fileName)
		if resultsError != nil {
			fmt.Printf("%v", resultsError)
		}
	} else {
		fmt.Println("the file name cant be empty")
	}
}

Output:

$ go run main.go "new"
this fileName new  doesn't exist

Explanation:- We are using errors.Is(readErr, fs.ErrNotExist) {} to check if the file passed exist, if it doesn’t exist we return custom message as shown above. we can also use the custom error message such as errors.New() to create expected error and handle it as errors.Is(readErr, fileNotFound) {} the return values will be the same.

ALSO READ: Golang Print Struct Variables [SOLVED]

Method 2:- Error wrapping

Wrapping is a way of using other errors within a function to provide more context and detailed error messages.

fmt.Error() function enable us to create a wrapped errors with use of %w flag. The %w flag is used for inspecting and unwrapping errors.
In this subtitles we can incorporate other functions from errors package used to handle errors, namely:- errors.As, errors.Is, errors.Unwrap functions. errors.As is used to cast a specific error type, i.e func As(err error, target any) bool{}, also, the errors.Unwrap is used to inspect and expose the underlying errors in a program,i.e func (e *PathError)Unwrap()error{ return e.Err}, Furthermore the errors.Is mostly for comparing error value against the sentinel value if is true or false, i.e func Is(err,target error) bool{}.

Example of Error Wrapping

package main

import (
	"errors"
	"fmt"
	"os"
)

func ReadFile(file string) error {
	dataFile, readErr := os.ReadFile(file)
	var pathError *os.PathError
	if readErr != nil {
		if errors.As(readErr, &pathError) {
			return fmt.Errorf("this fileName %s  doesn't exist and failed  opening file at this path %v", file, pathError.Path)
		}
		return fmt.Errorf("Error  occured while opening the file : %w", readErr)

	}
	fmt.Println(string(dataFile))
	return nil
}
func main() {
	fileName := os.Args[1]
	if fileName != "" {
		resultsError := ReadFile(fileName)
		if resultsError != nil {
			fmt.Printf("%v", resultsError)
		}
	} else {
		fmt.Println("the file name can't be empty")
	}
}

Output:

With the file attached ensure you replace the ReadFile(«test.txt»)

$ go run main.go
Hello

without file attached

$ go run main.go ""
the file name can't be empty

$ go run main.go next.txt
this fileName news.txt  doesn't exist and failed opening file at this path news.txt

Explanation:- In the above code we have used fmt.Errorf() functions to format the error message to be displayed and wrapping error using a custom error message with wrap function errors.Is() which checks if the path exists. You can avoid unnecessary error wrapping and handle it once.

ALSO READ: Golang SQLite3 Tutorial [With Examples]

Method-3: Using Panic, Defer and Recover

We have covered this topic in detail in a separate article Golang panic handing [capture, defer, recover, log]

Summary

At this point in this article, you have learned various ways to return and handle errors in the Golang function. In Go, Errors are considered to be a very lightweight piece of data that implements the Error interface. Custom errors in Go help in debugging and signaling where the error has occurred from. Error tracing is easy as compared to other programming languages. Golang application development, error handling is very critical and helps one not only during debugging but also to monitor the application behavior. We recommend you to read more about panic, recover and defer mechanism of error handling as well.

References

error-handling in Go
Working with errors in golang
Errors

Привет, уважаемые читатели Хабрахабра. В то время, как обсуждается возможный новый дизайн обработки ошибок и ведутся споры о преимуществах явной обработки ошибок, предлагаю рассмотреть некоторые особенности ошибок, паник и их восстановления в Go, которые будут полезны на практике.

error

error это интерфейс. И как большинство интерфейсов в Go, определение error краткое и простое:

type error interface {
    Error() string
}

Получается любой тип у которого есть метод Error может быть использован как ошибка. Как учил Роб Пайк Ошибки это значения, а значениями можно оперировать и программировать различную логику.

В стандартной библиотеки Go имеются две функции, которые удобно использовать для создания ошибок. Функция errors.New хорошо подходит для создания простых ошибок. Функция fmt.Errorf позволяет использовать стандартное форматирования.

err := errors.New("emit macho dwarf: elf header corrupted")

const name, id = "bimmler", 17
err := fmt.Errorf("user %q (id %d) not found", name, id)

Обычно для работы с ошибками достаточно типа error. Но иногда может потребоваться передавать с ошибкой дополнительную информацию, в таких случаях можно добавить свой тип ошибок.
Неплохой пример это тип PathError из пакета os

// PathError records an error and the operation and file path that caused it.
type PathError struct {
    Op   string
    Path string
    Err  error
}

func (e *PathError) Error() string { return e.Op + " " + e.Path + ": " + e.Err.Error() }

Значение такой ошибки будет содержать операцию, путь и ошибку.

Инициализируются они таким образом:

...
return nil, &PathError{"open", name, syscall.ENOENT}
...
return nil, &PathError{"close", file.name, e}

Обработка может иметь стандартный вид:

_, err := os.Open("---")
if err != nil{
    fmt.Println(err)
}
// open ---: The system cannot find the file specified.

А вот если есть необходимость получить дополнительную информацию, то можно распаковать error в *os.PathError:

_, err := os.Open("---")
if pe, ok := err.(*os.PathError);ok{
    fmt.Printf("Err: %sn", pe.Err)
    fmt.Printf("Op: %sn", pe.Op)
    fmt.Printf("Path: %sn", pe.Path)
}
// Err: The system cannot find the file specified.
// Op: open
// Path: ---

Этот же подход можно применять если функция может вернуть несколько различных типов ошибок.
play

Объявление нескольких типов ошибок, каждая имеет свои данные:

type ErrTimeout struct {
    Time time.Duration
    Err  error
}
func (e *ErrTimeout) Error() string { return e.Time.String() + ": " + e.Err.Error() }

type ErrPermission struct {
    Status string
    Err  error
}
func (e *ErrPermission) Error() string { return e.Status + ": " + e.Err.Error() }

Функция которая может вернуть эти ошибки:

func proc(n int) error {
    if n <= 10 {
        return &ErrTimeout{Time: time.Second * 10, Err: errors.New("timeout error")}
    } else if n >= 10 {
        return &ErrPermission{Status: "access_denied", Err: errors.New("permission denied")}
    }
    return nil
}

Обработка ошибок через приведения типов:

func main(){
    err := proc(11)
    if err != nil {
        switch e := err.(type) {
        case *ErrTimeout:
            fmt.Printf("Timeout: %sn", e.Time.String())
            fmt.Printf("Error: %sn", e.Err)
        case *ErrPermission:
            fmt.Printf("Status: %sn", e.Status)
            fmt.Printf("Error: %sn", e.Err)
        default:
            fmt.Println("hm?")
            os.Exit(1)
        }
    }
}

В случае когда ошибкам не нужны специальные свойства, в Go хорошей практикой считается создавать переменные для хранения ошибок на уровне пакетов. Примером может служить такие ошибки как io.EOF, io.ErrNoProgress и проч.

В примере ниже, прерываем чтение и продолжаем работу приложения, когда ошибка равна io.EOF или закрываем приложения при любых других ошибках.

func main(){
    reader := strings.NewReader("hello world")
    p := make([]byte, 2)

    for {
        _, err := reader.Read(p)
        if err != nil{
            if err == io.EOF {
                break
            }
            log.Fatal(err)
        }
    }
}

Это эффективно, поскольку ошибки создаются только один раз и используются многократно.

stack trace

Список функций, вызванных в момент захвата стека. Трассировка стека помогает получить более полное представление о происходящем в системе. Сохранение трассировки в логах может серьезно помочь при отладки.

Наличие этой информации в ошибке у Go часто не хватает, но к счастью получить дампа стека в Go не сложно.

Для вывода трассировки в стандартный выводов можно воспользоваться debug.PrintStack():

func main(){
    foo()
}

func foo(){
    bar()
}
func bar(){
    debug.PrintStack()
}

Как результат в Stderr будет записано такая информация:

goroutine 1 [running]:
runtime/debug.Stack(0x1, 0x7, 0xc04207ff78)
        .../Go/src/runtime/debug/stack.go:24 +0xae
runtime/debug.PrintStack()
        .../Go/src/runtime/debug/stack.go:16 +0x29
main.bar()
        .../main.go:13 +0x27
main.foo()
        .../main.go:10 +0x27
main.main()
        .../main.go:6 +0x27

debug.Stack() возвращает слайс байт с дампом стека, который можно в дальнейшем вывести в журнал или в другом месте.

b := debug.Stack()
fmt.Printf("Trace:n %sn", b)

Есть еще один момент, если мы сделаем вот так:

go bar()

то на выходе получим такую информацию:

main.bar()
        .../main.go:19 +0x2d
created by main.foo
        .../main.go:14 +0x3c

У каждой горутины отдельный стек, соответственно, мы получаем только его дамп. Кстати, о своих стеках у горутин, с этим еще связана работа recover, но об этом чуть позже.
И так, что бы увидеть информацию по всем горутинам, можно воспользоваться runtime.Stack() и передать вторым аргументом true.

func bar(){
    buf := make([]byte, 1024)
    for {
        n := runtime.Stack(buf, true)
        if n < len(buf) {
            break
        }
        buf = make([]byte, 2*len(buf))
    }
    fmt.Printf("Trace:n %sn", buf)
}

Trace:
 goroutine 5 [running]:
main.bar()
        .../main.go:21 +0xbc
created by main.foo
        .../main.go:14 +0x3c

goroutine 1 [sleep]:
time.Sleep(0x77359400)
        .../Go/src/runtime/time.go:102 +0x17b
main.foo()
        .../main.go:16 +0x49
main.main()
        .../main.go:10 +0x27

Добавим в ошибку эту информацию и тем самым сильно повысим ее информативность.
Например так:

type ErrStack struct {
    StackTrace []byte
    Err  error
}
func (e *ErrStack) Error() string {
    var buf bytes.Buffer
    fmt.Fprintf(&buf, "Error:n %sn", e.Err)
    fmt.Fprintf(&buf, "Trace:n %sn", e.StackTrace)
    return buf.String()
}

Можно добавить функцию для создания этой ошибки:

func NewErrStack(msg string) *ErrStack {
    buf := make([]byte, 1024)
    for {
        n := runtime.Stack(buf, true)
        if n < len(buf) {
            break
        }
        buf = make([]byte, 2*len(buf))
    }
    return &ErrStack{StackTrace: buf, Err: errors.New(msg)}
}

Дальше с этим уже можно работать:

func main() {
    err := foo()
    if err != nil {
        fmt.Println(err)
    }
}

func foo() error{
    return bar()
}
func bar() error{
    err := NewErrStack("error")
    return err
}

Error:
 error
Trace:
 goroutine 1 [running]:
main.NewErrStack(0x4c021f, 0x5, 0x4a92e0)
        .../main.go:41 +0xae
main.bar(0xc04207ff38, 0xc04207ff78)
        .../main.go:24 +0x3d
main.foo(0x0, 0x48ebff)
        .../main.go:21 +0x29
main.main()
        .../main.go:11 +0x29

Соответственно ошибку и трейс можно рзаделить:

func main(){
    err := foo()

    if st, ok := err.(*ErrStack);ok{
        fmt.Printf("Error:n %sn", st.Err)
        fmt.Printf("Trace:n %sn", st.StackTrace)
    }
}

И конечно уже есть готовые решение. Одно из них, это пакет https://github.com/pkg/errors. Он позволяет создавать новую ошибку, которая уже будет содержать стек трейс, а можно добавлять трейс и/или дополнительное сообщения к уже существующей ошибке. Плюс удобное форматирование вывода.

import (
    "fmt"
    "github.com/pkg/errors"
)

func main(){
    err := foo()
    if err != nil {
        fmt.Printf("%+v", err)
    }
}

func foo() error{
    err := bar()
    return errors.Wrap(err, "error2")
}
func bar() error{
    return errors.New("error")
}

error
main.bar
        .../main.go:20
main.foo
        .../main.go:16
main.main
        .../main.go:9
runtime.main
        .../Go/src/runtime/proc.go:198
runtime.goexit
        .../Go/src/runtime/asm_amd64.s:2361
error2
main.foo
        .../main.go:17
main.main
        .../main.go:9
runtime.main
        .../Go/src/runtime/proc.go:198
runtime.goexit
        .../Go/src/runtime/asm_amd64.s:2361

%v выведет только сообщения

error2: error

panic/recover

Паника(aka авария, aka panic), как правило, сигнализирует о наличии неполадок, из-за которых система (или конкретная подсистема) не может продолжать функционировать. В случае вызова panic среда выполнения Go просматривает стек, пытаясь найти для нее обработчик.

Необработанные паники прекращают работу приложения. Это принципиально отличает их от ошибок, которые позволяют не обрабатывать себя.

В вызов функции panic можно передать любой аргумент.

panic(v interface{})

Удобно в panic передать ошибку, того типа который упростит восстановления и поможет отладки.

panic(errors.New("error"))

Восстановление после аварии в Go основывается на отложенном вызове функций, он же defer. Такая функция гарантировано будет выполнена в момент возврата из родительской функции. Не зависимо от причины — оператор return, конец функции или паника.

А вот уже функция recover дает возможность получить информацию об аварии и остановить раскручивание стека вызовов.
Типичный пример вызова panic и обработчик:

func main(){
    defer func() {
        if err := recover(); err != nil{
            fmt.Printf("panic: %s", err)
        }
    }()
    foo()
}

func foo(){
    panic(errors.New("error"))
}

recover возвращает interface{} (тот самый который передаем в panic) или nil, если не было вызова panic.

Рассмотрим еще один пример обработки аварийных ситуаций. У нас есть некоторая функция в которую мы передаем например ресурс и которая в теории может вызвать панику.

func bar(f *os.File) {
    panic(errors.New("error"))
}

Во-первых, может понадобится всегда выполнять какие то действия при завершении, например очистка ресурсов, в нашем случае это закрытия файла.

Во-вторых, некорректное выполнение такой функции не должно приводить к завершению всей программы.

Такую задачу можно решить с помощью defer, recover и замыкания:

func foo()(err error) {
    file, _ := os.Open("file")
    defer func() {
        if r := recover(); r != nil {
            err = r.(error) // обрабатываем аварийную ситуацию, распаковываем если знаем, что в панике ошибка
            // err := errors.New("trapped panic: %s (%T)", r, r) // или создаем свою ошибку
        }
        file.Close() // закрываем файл
    }()

    bar(file)

    return err
}

Замыкание позволяем обратится к выше объявленным переменным, благодаря этому гарантировано закрываем файл и в случае аварии, извлечь из нее ошибку и передать ее обычному механизму обработки ошибок.

Бывают обратные ситуации, когда функция c определенными аргументами всегда должна отрабатывать корректно и если этого не происходит, то что пошло совсем плохо.

В подобных случаях добавляют функцию обертку в которой вызывается целевая функция и в случае ошибки вызывается panic.

В Go обычно такие функции с префиксом Must:

// MustCompile is like Compile but panics if the expression cannot be parsed.
// It simplifies safe initialization of global variables holding compiled regular
// expressions.
func MustCompile(str string) *Regexp {
    regexp, error := Compile(str)
    if error != nil {
        panic(`regexp: Compile(` + quote(str) + `): ` + error.Error())
    }
    return regexp
}

// Must is a helper that wraps a call to a function returning (*Template, error)
// and panics if the error is non-nil. It is intended for use in variable initializations
// such as
//  var t = template.Must(template.New("name").Parse("html"))
func Must(t *Template, err error) *Template {
    if err != nil {
        panic(err)
    }
    return t
}

Стоит помнить еще про один момент, связанный с panic и горутинами.

Часть тезисов из того что обсудили выше:

• Для каждой горутины выделяется отдельный стек.
• При вызове panic, в стеке ищется recover.
• В случае, когда recover не найдет, завершается все приложение.

Обработчик в main не перехватит панику из foo и программа аварийно завершится:

func main(){
    defer func() {
        if err := recover(); err != nil{
            fmt.Printf("panic: %s", err)
        }
    }()

    go foo()

    time.Sleep(time.Minute)
}
func foo(){
    panic(errors.New("error"))
}

Это будет проблемой, если например вызываются обработчик для соединения на сервере. В случае паники в любом из обработчиков, весь сервер завершит выполнение. А контролировать обработку аварий в этих функциях, по какой то причине, вы не можете.
В простом случае решение может выглядит примерно так:

type f func()

func Def(fn f) {
    go func() {
        defer func() {
            if err := recover(); err != nil {
                log.Println("panic")
            }
        }()

        fn()
    }()
}

func main() {
    Def(foo)

    time.Sleep(time.Minute)
}

func foo() {
    panic(errors.New("error"))
}

handle/check

Возможно в будущем нас ждут изменения в обработки ошибок. Ознакомится с ними можно по ссылкам:
go2draft
Обработка ошибок в Go 2

На сегодня все. Спасибо!