Free AI web copilot to create summaries, insights and extended knowledge, download it at here

1710

Abstract

e error message, and the URL is essential information for debugging.</p> <figure id="e56d"> <div> <div>

            <iframe class="gist-iframe" src="/gist/jerryan999/170d7ca4abd593db3ea4ea5c2de1079d.js" allowfullscreen="" frameborder="0" height="undefined" width="undefined">
          </div>
        </div>
    </figure></iframe></div></div></figure><p id="1e72">There are three tips of best practice to use this error handling strategy.</p><ul><li>First, the error message should be descriptive enough to help the user understand the problem.</li><li>Second, because error messages are frequently chained together, the message should not be capitalized, and newlines should be avoided</li><li>Third, the function caller and callee have different responsibilities to handle the error. The callee reports the attempted operation and the argument value related to the context of the error. The caller adds further context that it has, but the callee does not, such as the URL in the case <code>html.Parse </code>above.</li></ul><h1 id="aaed">Retry</h1><p id="ba8f">The second error handling strategy is retry. It is suitable for transient error cases, and the caller can retry the operation.</p><p id="bfc7">There are a lot of retry strategies, such as fixed backoff, exponential backoff, and random backoff. If you have interested in this topic, you can read more about it by searching the web.</p><p id="16fe">Here we implement a simple retry strategy that retries with exponential backoff for demonstrating the purpose.</p>
    <figure id="22d9">
        <div>
          <div>
            
            <iframe class="gist

Options

-iframe" src="/gist/jerryan999/170d7ca4abd593db3ea4ea5c2de1079d.js" allowfullscreen="" frameborder="0" height="undefined" width="undefined"> </div> </div> </figure></iframe></div></div></figure><h1 id="fc1c">Log the error and continue.</h1><p id="a47d">In some cases, it’s ok to tolerate an error. In such situations, the error is logged, and the program continues.</p> <figure id="fc56"> <div> <div>

            <iframe class="gist-iframe" src="/gist/jerryan999/170d7ca4abd593db3ea4ea5c2de1079d.js" allowfullscreen="" frameborder="0" height="undefined" width="undefined">
          </div>
        </div>
    </figure></iframe></div></div></figure><h1 id="5bce">Log and stop the program.</h1><p id="59ae">The fourth error handling strategy is to stop the program. The main function should generally use this strategy to terminate the program.</p>
    <figure id="2c94">
        <div>
          <div>
            
            <iframe class="gist-iframe" src="/gist/jerryan999/170d7ca4abd593db3ea4ea5c2de1079d.js" allowfullscreen="" frameborder="0" height="undefined" width="undefined">
          </div>
        </div>
    </figure></iframe></div></div></figure><h1 id="2c87">Summary</h1><p id="f0a4">Error handling in Go is essential. Now, let’s start to enjoy the happy journey of error handling with the four strategies.</p><p id="c2b9">I hope you enjoyed reading this. If you’d like to support me as a writer, consider becoming<a href="https://jerryan.medium.com/membership"> a Medium member</a>. You’ll also get unlimited access to every story on Medium.</p></article></body>

Error Handling Strategies In Go

Photo by Possessed Photography on Unsplash

In Go, when a function call returns an error, it’s the caller’s responsibility to check it and take appropriate action. There may be several strategies to handle it.

In this post, let’s take a look at the following four options:

Propagate
Retry
Log and continue.
Log and stop the program.

Propagate

The most common way is returning the error directly. So that failure in a subroutine is propagated up to the caller.

In the following example, if the call http.Getfails, the HTTP error is returned without further processing.

Sometimes, it is necessary to wrap some pieces of descriptive information in error so that it is helpful to us.

In the following example, we use the functionfmt.Errorf to wrap the error message with a string. It includes the request URL and the error message, and the URL is essential information for debugging.

There are three tips of best practice to use this error handling strategy.

First, the error message should be descriptive enough to help the user understand the problem.
Second, because error messages are frequently chained together, the message should not be capitalized, and newlines should be avoided
Third, the function caller and callee have different responsibilities to handle the error. The callee reports the attempted operation and the argument value related to the context of the error. The caller adds further context that it has, but the callee does not, such as the URL in the case html.Parse above.

Retry

The second error handling strategy is retry. It is suitable for transient error cases, and the caller can retry the operation.

There are a lot of retry strategies, such as fixed backoff, exponential backoff, and random backoff. If you have interested in this topic, you can read more about it by searching the web.

Here we implement a simple retry strategy that retries with exponential backoff for demonstrating the purpose.

Log the error and continue.

In some cases, it’s ok to tolerate an error. In such situations, the error is logged, and the program continues.

Log and stop the program.

The fourth error handling strategy is to stop the program. The main function should generally use this strategy to terminate the program.

Summary

Error handling in Go is essential. Now, let’s start to enjoy the happy journey of error handling with the four strategies.

I hope you enjoyed reading this. If you’d like to support me as a writer, consider becoming a Medium member. You’ll also get unlimited access to every story on Medium.