Returning multiple errors as a slice

<p>Would it be considered bad practice to do something like <a href="https://play.golang.org/p/gMSQKcsrqe">https://play.golang.org/p/gMSQKcsrqe</a> ?</p> <p>The thought behind it is it would be a great way to return an error array for an API - for instance, a member service with a New function could return an error for each invalid parameter.</p> <p>Would love to hear thoughts on this method.</p> <p><strong>Update:</strong> Probably going to implement something like this instead, based on the comments: <a href="https://play.golang.org/p/n1a4vZWtUC">https://play.golang.org/p/n1a4vZWtUC</a>. Feedback?</p> <hr/>**评论：**<br/><br/>natefinch: <pre><p>I don&#39;t think it is a great idea to return a slice of errors for a single action. If someone calls New and gets a slice of errors back, and they want to return some error to their caller... how do they do that? Which one do they choose?</p> <p>Just return one error. If you need to give it more information, you can do that through interfaces.</p> <p>Give it a InvalidProperties() []string method or something.</p> <p>IMO, the only time it&#39;s appropriate to return a slice of errors is if the user has asked you to do N independent actions in a bulk request... like </p> <p>func DeleteUsers(ids []UserID) []error</p> <p>In which case I&#39;d expect the slice of errors to be a 1:1 mapping based on index to the passed in IDs (so you could have not found errors or not authorized errors etc per user)</p></pre>beeker1121: <pre><p>I think you&#39;re right with just returning one error, it&#39;s probably the cleaner way of doing it vs having two returned with one being the slice. Going to look further into using an interface, thank you!</p></pre>beeker1121: <pre><p>So here&#39;s what I might end up implementing, let me know what you think.</p> <p>Goal is to have a main <code>services</code> package which implements backend functions, such as adding a new member to the database.</p> <p>This package will be used by dash routes as well as the API.</p> <p>For handling API parameter errors, I&#39;m planning on returning a custom <code>ParamErrors</code> type which is a slice, where each error in the slice refers to a specific parameter.</p> <p>To handle this with the service in Go, here&#39;s the code: <a href="https://play.golang.org/p/n1a4vZWtUC" rel="nofollow">https://play.golang.org/p/n1a4vZWtUC</a></p></pre>offero: <pre><p>errors.Wrap</p></pre>itsmontoya: <pre><p>I use the ErrorList from the errors package from Meteora&#39;s toolkit.</p> <p><a href="http://github.com/missionMeteora/toolkit" rel="nofollow">http://github.com/missionMeteora/toolkit</a></p></pre>HectorJ: <pre><p>+1 for this</p> <p>Not adding one dependency to your project, but having a type which groups your <code>error</code>s and implements <code>error</code> itself.</p></pre>lespritd: <pre><p>A slightly less good errorList is in go/scanner, if you&#39;d really prefer a no-dependency solution.</p></pre>beeker1121: <pre><p>Thanks!</p></pre>beeker1121: <pre><p>It does seem like it&#39;s a better way, especially if certain methods that know they&#39;re receiving a multiple error type can handle it accordingly, and those that don&#39;t will never know the difference, like you show.</p></pre>beeker1121: <pre><p>Thanks!</p></pre>xargon7: <pre><p>That&#39;s good, there are a variety of multierror packages too: <a href="https://godoc.org/?q=multierror" rel="nofollow">https://godoc.org/?q=multierror</a></p></pre>postman_: <pre><p>Blame golang&#39;s shitty type system. They could make a tuple type and then multiple return values would be just a syntactic sugar over it.</p></pre>natefinch: <pre><p>Meh? The only real special thing about tuples is that they have syntactic sugar to extract them, e.g.</p> <pre><code>x, y, z = point3d </code></pre> <p>There&#39;s almost never a time when I&#39;d use a tuple rather than a struct, which is effectively the same thing, except that you use named fields instead of the position in the tuple, which is way less error prone anyway:</p> <pre><code>x, y, z := p.X, p.Y, p.Z </code></pre></pre>postman_: <pre><p>You could iterate over the tuple which is needed for the use-case presented in OP.</p></pre>natefinch: <pre><p>then how is it better than a slice of errors?</p></pre>