FAQ
Could be added a type to handle a list of errors to the package "errors" ?

Just like it is in "go/scanner": http://golang.org/pkg/go/scanner/#ErrorList
but without the argument "token.Position".

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Tahir at Sep 6, 2014 at 2:12 pm
    Why without token position ? You just want to push the error on a stack ?
    Then you cannot prioritize/sort the error list anymore.

    Imo, It might not actually be ultra necessary to add it to the standard
    lib.. the errors package seems to really be a very tiny convenience package
    around the error type. You could really create your own little library by
    almost copy-pasting the implementation in scanner pkg and the errors pkg.

    http://golang.org/src/pkg/go/scanner/errors.go?s=853:876#L27
    http://golang.org/src/pkg/errors/errors.go
    On Saturday, September 6, 2014 1:30:30 PM UTC+1, Archos wrote:

    Could be added a type to handle a list of errors to the package "errors" ?

    Just like it is in "go/scanner":
    http://golang.org/pkg/go/scanner/#ErrorList
    but without the argument "token.Position".
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Archos at Sep 6, 2014 at 5:06 pm
    El sábado, 6 de septiembre de 2014 15:12:55 UTC+1, Tahir escribió:
    Why without token position ? You just want to push the error on a stack ?
    Then you cannot prioritize/sort the error list anymore.
    The token position is useful when you scan a file, bu it is useless when
    you only need to store a list of errors for whatever reason.

    Imo, It might not actually be ultra necessary to add it to the standard
    lib.. the errors package seems to really be a very tiny convenience package
    around the error type. You could really create your own little library by
    almost copy-pasting the implementation in scanner pkg and the errors pkg.
    I am already using an own library but I've seen that other people also
    needs a list of errors so it could be useful if it were in the standard
    library.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Eric Johnson at Sep 7, 2014 at 6:05 pm
    I'm also in favor of a library implementation of an error list. Various occasions where multiple errors can occur. I ran into this problem while recovering from errors during database operations. Close operations may return errors. Don't want to lose the multiple possible errors on close, but also don't want to lose the original error.

    Ended up implementing an ErrorList.

    Is filing an enhancement bug appropriate?

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Andrew Gerrand at Sep 8, 2014 at 6:25 am
    I don't think there's any one implementation of an ErrorList that would
    suffice for most tasks.

    In its simplest form it is just a few lines of code, so the standard
    library version wouldn't be of much benefit.

    I think it is better that such types be implemented as part of a package
    API, rather than something that is provided by the standard library.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Kyle Lemons at Sep 8, 2014 at 4:30 pm

    On Sun, Sep 7, 2014 at 11:24 PM, Andrew Gerrand wrote:

    I don't think there's any one implementation of an ErrorList that would
    suffice for most tasks.
    My favorite argument for having it in the standard library is that its
    usage can become more widespread (and thus more familiar to authors and
    users) and there can be canonical examples of how to use it properly. In
    particular, I've seen a number of one-off implementations of errorList that
    would sometimes return a zero-length slice implementation of error, thus
    foiling err != nil checks.

    Straw-man API:

    package errors

    // FromSlice returns an error describing the slice of errors.
    // If a nonzero number of non-nil errors are given, the returned error is a
    *List with all given errors.
    // If no errors are given or all given errors are nil, a nil error is
    returned.
    // The given string prefix is used in the error text of the error summary.
    FromSlice(prefix string, errors ...error) error

    // A List represents a list of errors, often corresponding one-to-one to a
    set of inputs.
    type List struct {
       // contains unexported fields
    }

    // Errors returns the list of errors contained in this List.
    func (l *List) Errors() []error

    // Error returns a summary string describing the errors.
    func (l *List) Error() string

    In its simplest form it is just a few lines of code, so the standard
    library version wouldn't be of much benefit.

    I think it is better that such types be implemented as part of a package
    API, rather than something that is provided by the standard library.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Varialus at Sep 9, 2014 at 12:28 pm

    On Monday, September 8, 2014 12:25:14 AM UTC-6, Andrew Gerrand wrote:
    I don't think there's any one implementation of an ErrorList that would
    suffice for most tasks.

    In its simplest form it is just a few lines of code, so the standard
    library version wouldn't be of much benefit.

    I think it is better that such types be implemented as part of a package
    API, rather than something that is provided by the standard library.
    I happened across a link to an error package the other day that was
    interesting enough that I bookmarked it. It chains errors together and also
    has some other very nice features. https://github.com/amattn/deeperror

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Eric Johnson at Sep 15, 2014 at 9:45 pm
    I've done an ErrorList implementation built mostly around one function:

    func CollectErr(err, newErr error) error {
    ...
    }

    If both parameters are nil, the result is nil.

    If one of the parameters is nil, return the other.

    If both of the parameters are of type ErrorList, append all the errors from
    the second onto the first.

    If one of the parameters is of type ErrorList, append the other parameter

    Create a new ErrorList, with two errors on it.

    That seems to me to be a good way to collect multiple errors into an
    ErrorList.

    This eliminates the [] == nil problem, and rolls up multiple errors into a
    single return.

    Useful?

    Eric.
    On Mon, Sep 8, 2014 at 6:48 PM, wrote:
    On Monday, September 8, 2014 12:25:14 AM UTC-6, Andrew Gerrand wrote:

    I don't think there's any one implementation of an ErrorList that would
    suffice for most tasks.

    In its simplest form it is just a few lines of code, so the standard
    library version wouldn't be of much benefit.

    I think it is better that such types be implemented as part of a package
    API, rather than something that is provided by the standard library.
    I happened across a link to an error package the other day that was
    interesting enough that I bookmarked it. It chains errors together and also
    has some other very nice features. https://github.com/amattn/deeperror
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedSep 6, '14 at 12:30p
activeSep 15, '14 at 9:45p
posts8
users6
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase