The first question you need to ask yourself is are you going to use errors as values ( if err == myerrors.ErrValue ) or errors as types ( if e,ok:= err.(*myerrors.ErrType ; ok )
Le samedi 10 décembre 2016 20:10:26 UTC+1, Jon a écrit : > > I would like to know what my default practice should be when returning > structs from functions. Should I return a value or a pointer? (Assume I > don't need the functionality of returning a pointer and my struct contains > at most one simple field so a vast copy isn't needed if I return a value.) > > A specific example could be the errors package > <https://golang.org/src/errors/errors.go> with errors.New. > > The New function is implemented by returning an errorString pointer: > <https://play.golang.org/p/WPmP8ZVS0_> > > func New(text string) error { > return &errorString{text} > } > > Could it just as easily have been implemented by returning an errorString > value <https://play.golang.org/p/Gawy-mgw2X>? If so why was the pointer > return chosen over value return? > > func New(text string) error { > return errorString{text} > } > > Could it also have been implemented as below > <https://play.golang.org/p/H2NIARHO-Y> which looks even simpler? > > func New(text string) error { > return errorString(text) > } > // errorString is a trivial implementation of error. > type errorString string > > func (e errorString) Error() string { > return string(e) > } > > What was the thought process that went into the implementation of the > errors package? Were the latter two implementation options I suggest > considered? If so why were they disregarded? Performance? Coding standards? > Heap allocation benefits? > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
