Returning multiple errors as a slice

Would it be considered bad practice to do something like https://play.golang.org/p/gMSQKcsrqe ?

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.

Would love to hear thoughts on this method.

Update: Probably going to implement something like this instead, based on the comments: https://play.golang.org/p/n1a4vZWtUC. Feedback?

---

评论：

natefinch:

I don'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?

Just return one error. If you need to give it more information, you can do that through interfaces.

Give it a InvalidProperties() []string method or something.

IMO, the only time it'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 

func DeleteUsers(ids []UserID) []error

In which case I'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)

beeker1121:

I think you're right with just returning one error, it'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!

beeker1121:

So here's what I might end up implementing, let me know what you think.

Goal is to have a main services package which implements backend functions, such as adding a new member to the database.

This package will be used by dash routes as well as the API.

For handling API parameter errors, I'm planning on returning a custom ParamErrors type which is a slice, where each error in the slice refers to a specific parameter.

To handle this with the service in Go, here's the code: https://play.golang.org/p/n1a4vZWtUC

offero:

errors.Wrap

itsmontoya:

I use the ErrorList from the errors package from Meteora's toolkit.

http://github.com/missionMeteora/toolkit

HectorJ:

+1 for this

Not adding one dependency to your project, but having a type which groups your errors and implements error itself.

lespritd:

A slightly less good errorList is in go/scanner, if you'd really prefer a no-dependency solution.

beeker1121:

Thanks!

beeker1121:

It does seem like it's a better way, especially if certain methods that know they're receiving a multiple error type can handle it accordingly, and those that don't will never know the difference, like you show.

beeker1121:

Thanks!

xargon7:

That's good, there are a variety of multierror packages too: https://godoc.org/?q=multierror

postman_:

Blame golang's shitty type system. They could make a tuple type and then multiple return values would be just a syntactic sugar over it.

natefinch:

Meh?  The only real special thing about tuples is that they have syntactic sugar to extract them, e.g.

x, y, z = point3d

There's almost never a time when I'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:
x, y, z := p.X, p.Y, p.Z

postman_:

You could iterate over the tuple which is needed for the use-case presented in OP.

natefinch:

then how is it better than a slice of errors?