Wrapping Errors in Go – How to Handle Nested Errors

Errors in Go (Golang) are a hot topic. Many newcomers to the language immediately level their first criticism, "errors in go are clunky! Let me try and catch!" This criticism is well-meaning but misguided.
Click To Tweet

By Lane Wagner @wagslane on Twitter

The paradigm of errors as a type, rather than something to be thrown and cause panics, allows for more control of how to handle “bad” state. It also forces developers to think about errors at every step.

What will go wrong here? How should I handle it?

There are plenty of articles that discuss the pros/cons of error handling in Go. I want to talk specifically about how the clunky (albeit better) handling of errors in Go can lead to a common problem: nested errors.

The Called Function

To demonstrate the problem of nested errors, let’s take a look at the following function:

func isInRange(i int) error {
        const min = 5
        const max = 10
        if i < 5 || i > 10 {
                return fmt.Errorf("isInRange: %v must be between %v and %v", i, min, max)
        }
        return nil
}

isInRange() is a simple function that checks if a number is between two other predefined numbers, and returns a formatted error message in case the number is out of range.

The Calling Function

func getNumberFromStdIn() (int, error) {
        reader := bufio.NewReader(os.Stdin)
        text, _, err := reader.ReadLine()
        if err != nil {
                return 0, err
        }
        i, err := strconv.Atoi(string(text))
        if err != nil {
                return 0, err
        }
        err = isInRange(i)
        if err != nil {
                return 0, err
        }
        return i, nil
}

As you can see, getNumberFromStdIn() calls isInRange(). The problem with the above code is that if an error happens within getNumberFromStdIn() and subsequently is logged to the console, it is almost impossible to tell where the error came from.

For example, if isInRange’s error is logged to the console during execution:

isInRange: 3 must be between 5 and 10

Where did this come from? We know that isInRange() created the error, but we don’t know where isInRange() was called. Was isInRange() called by getNumberFromStdIn()? Or somewhere else? Perhaps we grep through our codebase and see that isInRange() is called hundreds of times! Now our task to find the root of the error becomes much more difficult than it needs to be.

Solution: Wrap The Errors

func getNumberFromStdIn() (int, error) {
        reader := bufio.NewReader(os.Stdin)
        text, _, err := reader.ReadLine()

        const fName = "getNumberFromStdIn"
        if err != nil {
                return 0, fmt.Errorf("%v: %v", fName, err)
        }
        i, err := strconv.Atoi(string(text))
        if err != nil {
                return 0, fmt.Errorf("%v: %v", fName, err)
        }
        err = isInRange(i)
        if err != nil {
                return 0, fmt.Errorf("%v: %v", fName, err)
        }
        return i, nil
}

Now, when isInRange() is called in this specific location, we get a formatted message:

getNumberFromStdIn: isInRange: 3 must be between 5 and 10

By wrapping errors and building well-formatted error messages, we can keep better track of where errors are happening.

Should I Always Wrap Errors?

Nope. Like all rules-of-thumb, there are exceptions.

For example, if I’m writing a package that exposes the function getNumberFromStdIn() then my users (programmers using my package) don’t need to know that atoi() failed, they just need to know that getNumberFromStdIn() failed. I don’t need to wrap any errors. In fact, I can probably ignore the underlying error and create my own message from scratch.

If it is glaringly obvious where an error comes from, there is also less reason to wrap it. Wrapping an error, in theory, should never hurt, but it can be unnecessary work. Look at everything on a case-by-case basis.

Thanks For Reading

Lane on Twitter: @wagslane

Lane on Dev.to: wagslane

Download Qvault: https://qvault.io

The post Wrapping Errors in Go – How to Handle Nested Errors appeared first on Qvault.



source https://qvault.io/2020/03/09/wrapping-errors-in-go-how-to-handle-nested-errors/?utm_source=rss&utm_medium=rss&utm_campaign=wrapping-errors-in-go-how-to-handle-nested-errors

Comments

Post a Comment

Popular posts from this blog

Why is Exclusive Or (XOR) Important in Cryptography?

Image
If you are getting into cryptography, or just trying to understand the fundamentals, you may have noticed that the exclusive-or operation is used quite often, especially in ciphers. What is XOR ( ⊕ )? XOR, or “exclusive or” operates on binary data. It returns true if both of its inputs are opposites (one false and one true), otherwise, it returns false. An example in go code would be something like: func exclusiveOr(a bool, b bool) bool { return a != b } XOR Cipher – The Perfect Cipher The XOR operation can be used as a simple cipher for encrypting and decrypting messages with a single key. This is known as symmetric encryption. It is interesting to note that if: The key is the same size as the message The key is kept secret and generated truly randomly Then the cipher is impossible to crack. This is known as a one time pad . However, a simple XOR shouldn’t be used in production due to the key length needing to be too long to be practical. Cipher Example A...
Read more

Base64 vs Base58 Encoding

Image
By Lane Wagner –  @wagslane  on Twitter Base64 is one of the most popular encoding formats for representing data. Have some binary data? Base64 encode it for convenient readability and parsing. Base58 is just another encoding format (with 58 characters instead of 64, and has gained popularity largely due to Bitcoin and other cryptocurrencies. When it comes to data encoding, there is typically a trade-off made between: Human Readability: Do humans have a good idea of what is being represented at a glance? Efficient data compression: How many bytes are used to represent the same data? Let’s rank Base58, Base64, and ASCII encoding against each other using these metrics! First: A Note on Binary All data is stored in a raw binary format on computers. These encoding formats (Base64, Base58, and ASCII) are just different ways of reading and writing binary data. For example, in Base64 the binary code 000000 represents the letter A , but in ASCII the binary 00000000 repres...
Read more

(Very) Basic Intro to Hash Functions (SHA-256, MD-5, etc)

Image
This is going to be a basic introduction to hash functions. I will assume most of my audience is here to gain an understanding of why hash functions are used and the basic idea of why they work. My goal is to explain it in a general sense, I will be omitting proofs and implementation details and instead focusing on the high-level principles. Why Use A Hash Function? Hash functions are used all over the internet in order to securely store passwords, find duplicate records, quickly store and retrieve data, and more. For example,  Qvault  uses hashes to extend master passwords into private encryption keys. A longer list of uses here:  https://en.wikipedia.org/wiki/Hash_function#Uses I want to focus on several important features of hash functions, arguably the most important features. Hash functions scramble data deterministically No matter the input, the output of a hash function always has the same size The original data can not be retrieved from the scrambled d...
Read more