<p>How would you refactor the error handling in this function to not include multiple if err return statements.</p>
<pre><code>func (client *APIClient) GetLocationsByDistance() (string, error) {
//for now just return straight from server
locations, err := client.getLocationsFromServer()
if err != nil {
return "", err
}
data, err := json.Marshal(locations)
if err != nil {
return "", err
}
return string(data), nil
}
</code></pre>
<hr/>**评论：**<br/><br/>venju: <pre><p>I understand why you would want to do this, but an abundance of multiple returns is Go tradition, so it is what you should write if you expect other people to read your code.</p>
<p>There are some circumstances where you can abstract away the generation of errors, especially when making lots of calls to the same function which returns an error. <a href="https://blog.golang.org/errors-are-values" rel="nofollow">Here is a blog post Rob Pike wrote about that.</a>.</p>
<p>If you are in control of the errors you return, you have a lot more leeway if you design correctly. Errors are values, so you can do some neat stuff.</p>
<p>In general gophers write, and expect to read, very explicit possibly redundant concrete code without much abstraction. Think C philosophy not haskell philosophy.</p>
<p>To be clear because this a "heated" topic I'm not making a statement about which philosophy is better; I just think recognizing and assimilating to a language's culture is the correct decision unless there is a <strong>strong</strong> argument for an alternative method.</p></pre>nevyn: <pre><p>Why would you want to?</p>
<p>If the answer is "Because it's my homework and it says to do that" then it should also at least give hints on the way they want you to transform it.</p></pre>caseynashvegas: <pre><p>Not exactly homework, lol. Yes, the code is already pretty clean, but what if there were 3 or 4? I am just wondering what other professionals are doing. I don't like functions with multiple return statements in general. </p></pre>gbitten: <pre><blockquote>
<p>I don't like functions with multiple return statements in general. </p>
</blockquote>
<p>Welcome to Go World, we love multiple returns.</p></pre>hgjkghjkhgfhf: <pre><p>So, now you know two issues that you have to work through to be a better Go programmer. Early returns and 'if err != nil' are the norm in Go. Those among us might even say 'idiomatic' go.</p></pre>iwsbfgl: <pre><p>I believe a lot of the dislike of multiple returns come from an overzealous adherence too Dijkstra's Single Entry, Single Exit paper. See this <a href="http://softwareengineering.stackexchange.com/a/118793" rel="nofollow">SO question</a> for more on that. I hadn't even realized it refernecing returning to different locations, not multiple exit points. Either way, this has become an often recited axiom in school. </p>
<p>Where did that leave us? Dijkstra was advocating code that was easier to reason about and debug. Applying that to Go and other modern languages gives me my preferred style. I want to easily spot where a function exits. I want a single exit with a value. This allows me to easily add logging with the return value at the end of a function. I want to return early and often for errors. This means I don't need a lot of nested blocks of code, each of each checking for a other error. But to easily figure out where the function returns, each error must be unique. And no, the line number doesn't count. Those change to frequently. I want to errors that say failed to open file, then failed to read file, then failed to parse Jason from file, then an error saying a required field is missing. From those errors, I can easily reason about where the function exited.</p></pre>danredux: <pre><p>Adding logging to your return statements even when there are multiple exits is easy.</p>
<pre><code>func LogMe() (n string) {
defer func(){
fmt.Println(n)
}()
if 1 > 2 {
return "impossible"
}
return "good"
}
</code></pre></pre>iwsbfgl: <pre><p>Interesting technique. Thank you. </p></pre>driusan: <pre><pre><code>func (client *APIClient) GetLocationsByDistance() (string, error) {
//for now just return straight from server
locations, _ := client.getLocationsFromServer()
data, _ := json.Marshal(locations)
return string(data), nil
}
</code></pre>
<p>(please don't do this.)</p></pre>danredux: <pre><p>There is a solution to this using what are essentially "maybe monads".</p>
<p>Here is a complete example (the "error" case emulated here is if you pass in a string that is not a valid integer).</p>
<p><a href="https://play.golang.org/p/-lOEmguvEk" rel="nofollow">https://play.golang.org/p/-lOEmguvEk</a></p>
<p>It ends up looking like this:</p>
<pre><code>func (client *APIClient) GetLocationsByDistance() (string, error) {
//for now just return straight from server
locations := client.getLocationsFromServer()
data := locations.Marshal()
return data.Unbox()
}
</code></pre></pre>caseynashvegas: <pre><p>Very interesting example.</p></pre>hgjkghjkhgfhf: <pre><p>I wouldn't change a thing, this is how error handling is done in Go.</p></pre>
