Go Language Error Handling: Difference between revisions
Line 56: | Line 56: | ||
==Wrapping Errors== | ==Wrapping Errors== | ||
{{External|https://golang.org/pkg/fmt/#Errorf}} | {{External|https://golang.org/pkg/fmt/#Errorf}} | ||
Errors can be wrapped to add additional information, by using the <code>fmt.Errorf()</code> function call and the <code>%w</code> formatter. | Errors can be wrapped to add additional information, by using the <code>fmt.Errorf()</code> function call and the <code>%w</code> formatter. | ||
<code>fmt.Errorf()</code> returns an instance that satisfies the <code>error</code> interface. | |||
<syntaxhighlight lang='go'> | <syntaxhighlight lang='go'> | ||
if err != nil { | if err != nil { |
Revision as of 19:47, 6 September 2023
Internal
Overview
A common error generation pattern in Go is that function return an error instance as the second return value. In case of correct operation, the second return value is nil
. If there's an error, then the second parameter has a non-nil
value.
Explicit error handling is some times cited as one of the strong points of Go.
The returned error instance is implements the error
interface:
type error interface {
Error() string
}
The Error()
method prints the error message.
The error
interface is a pre-declared type identifier.
Idiomatic Error Handling
f, err := os.Open("...")
if err != nil {
fmt.Println(err) // will call the Error() method
return
}
f, err := os.Open("...")
if err != nil {
return errors.New("something went wrong")
}
var somethingWentWrong = errors.New("something went wrong")
f, err := os.Open("...")
if err != nil {
return somethingWentWrong
}
Use panics in truly exceptional cases.
Do not discard errors by using the blank identifier _
assignment, aways handle each error.
When calling a function returning an error, always handle the error first.
Error strings should start with a lowercase character, unless they begin with names that require capitalization.
Error strings, unlike comments, should not end with punctuation marks.
Wrapping Errors
Errors can be wrapped to add additional information, by using the fmt.Errorf()
function call and the %w
formatter.
fmt.Errorf()
returns an instance that satisfies the error
interface.
if err != nil {
return fmt.Errorf("something failed: %w", err)
}
The errors
package contains code to handle wrapped errors.
TO DEPLETE
Organizatorium
Create an error:
errors.New("at least three arguments are required")
External
- Go Specification - Handling panics https://golang.org/ref/spec#Handling_panics
Overview
Error are not types, they are interfaces.
The error Type
Go has a built-in error type. It is an interface. Its definition can be found in $GO_HOME/src/builtin/builtin.go. According to the documentation: the error built-in interface type is the conventional interface for representing an error condition, with the nil value representing no error.
The "errors" Package
Creating Custom error Instances
errors.New()
Custom errors can be created by using the New() function in the "errors" package. Returns an error pointer:
import "errors" ... errPtr := errors.New("some text")
fmt.Errorf()
The function fmt.Errorf() also creates custom error instances.
Exceptions
Exceptions (in the Java sense) are not available in Go.
An alternative mechanism can be implemented by function returning multiple values, out of which one is an error indicator.
panic
defer and finally
defer puts the function on the stack.
Panics
A panic generally indicates a programmer error (attempting to access an array index out of bounds, writing an uninitialized map, etc.) Panics can also be synthetically triggered with:
panic(message)
The panic can be caught on the stack outside the function that caused the panic, by executing recover(). Recover can be called in any upper function on the stack, or even if the function that triggers the panic, if the invocation is made with defer.
The recover() built-in function allows a program to manage behavior of a panicking goroutine. Executing a call to recover inside a deferred function (but not any function called by it) stops the panicking sequence by restoring normal execution and retrieves the error value passed to the call of panic. If recover is called outside the deferred function it will not stop a panicking sequence. In this case, or when the goroutine is not panicking, or if the argument supplied to panic was nil, recover returns nil. Thus the return value from recover reports whether the goroutine is panicking.
Error Handling Idioms
The fact that Go function can return multiple value may be used in implementing a mechanism where a function returns the "good" value and an error value, instead of an exception. If an error occurs (the error instance is not nil), you should never trust the other values being returned by the function, they should always be ignored. This is an idiomatic way of handling errors returned by functions. For a callee function A and a calling function B:
// the "callee" func A(...) (<business-result-type>, error) { var result <business-result-type> // processing ... // some error occurs return <zero-value-for-type>, errors.New("dang") // all good, make sure to return all values, including a nil error return result, nil } // the calling function func B(...) (<business-result-type>, error) { result, err := A(...) if err != nil { return <zero-value-for-type>, err } // process the callee's returned result ... // all good, make sure to return all values, including a nil error return result, nil }
The fact that functions return error values can be used in conjunction with the special if syntax:
if value, error := f(); err { // handle err } else { // handle success }
More about multiple return values can be found here: