[go-nuts] Re: Does fmt.Print* automatically render an error string in as struct (play link)
You have implemented error on *Thing, so it is *that* which fmt is running,
which then in turn runs the implementation from your wrapped error.
If you don't wish fmt to treat your *Thing as an error, you must remove
method Error() string from it.
On Tuesday, August 28, 2018 at 5:15:31 PM UTC-7, Louki Sumirniy wrote:
>
> I discovered quite by accident and now I can't find anything saying as
> such, but this example
>
> package main
>
> import (
> "fmt"
> "errors"
> )
>
> type Thing struct {
> err error
> }
>
> type thing interface {
> Error() string
> }
>
> func (t *Thing) Error() string {
> return t.err.Error()
> }
>
> func main() {
> t := new(Thing)
> t.err = errors.New("testing")
> fmt.Println(t)
> }
>
> https://play.golang.org/p/xBIGIvSZkqO
>
> as you can see by running it, prints the error value inside the struct.
>
> I am writing a library where I am using a 'pipeline' model so I can string
> pointer methods together in a chain, which requires putting an error value
> inside the structure, and then it does this when I print the struct. It's
> quite handy but unexpected. I assume if a struct satisfies the error
> interface it calls it to generate the string.
>
--
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.
[go-nuts] Re: Keep Vendor folder on library Repository is Bad or Good practice.
On Saturday, July 28, 2018 at 11:43:04 AM UTC-7, nafis wrote: > > Suppose I'm making a library and it does reference some other library not > part of the standard library. I want to vendor those so that my library > doesn't fail if the other 3rd party developer deletes their library or > major changes of their library(I know this sound like stupid design). And I > want to push the vendor folder on my library repo. My question: Is this > the bad idea keep a vendor folder on the library repo. > > Thank you for your time. > There are some practical considerations to vendoring within a library: 1. If any types from a vendored package appear in the exported interface of your library, no caller will be able to write down the full names of those types because their imports are not from your vendored package path, and so your library may be difficult to use. 2. If the package you are vendoring does anything that relies on the full resolved package path at runtime -- for example, gob encoding uses it by default via reflection when registering types -- then the copy in your vendor directory will see the vendor package path, which may cause problems if the resulting value leaves your program and must be consumed by another program that was expecting the "canonical" path. I believe if neither of these are true for your library then the decision is entirely internal to your library and callers will not be able to observe any difference compared to a non-vendored copy of the same dependency. -- 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.
