Of course this happens when you don't test your code ^^ Here is a version without compilation errors and with a quick demo: https://play.golang.org/p/ykO4igrC0b1
On Thu, Apr 5, 2018 at 2:06 PM, Axel Wagner <axel.wagner...@googlemail.com> wrote: > On Thu, Apr 5, 2018 at 1:58 PM, Mateusz Czaplinski <czapko...@gmail.com> > wrote: > >> Reading from it and handling the errors is left to user. >> > > Then why would this need to live in the stdlib? For example here is a > quick and dirty implementation that allows the same functionality, without > having to modify the stdlib: > https://play.golang.org/p/_TsQQUhs8Ik > This could be provided as a normal package and people can use it to > augment any io.Closer (and, really, by extension anything) with this > functionality. > > >> There are many possible ways to handle it, so it's hard to guess in the >> finalizer what user wants: >> a) print them on stderr >> b) push them to some logging infrastructure >> c) just plain ignore them (default behavior) >> User may not want or expect to have stderr trashed by some messages from >> libraries. Passing the errors through a common channel can help opt-in to >> the feature. >> >> On Thu, Apr 5, 2018 at 1:55 PM, Axel Wagner < >> axel.wagner...@googlemail.com> wrote: >> >>> What would the runtime.Leaks channel do with the received errors? Why >>> can't you just do the same thing from the finalizer itself? >>> >>> On Thu, Apr 5, 2018 at 1:43 PM, Mateusz Czapliński <czapko...@gmail.com> >>> wrote: >>> >>>> Based on a recent discussion on reddit, and a reply by BowsersaurusRex: >>>> >>>> "In C# I'll often use finalizers to track bugs in which an object >>>> was GC'd but Close() was never called." >>>> >>>> I submitted the following proposal: >>>> >>>> https://golang.org/issue/24696 >>>> >>>> I'd love to see a solution which would not require adding to package >>>> runtime, but as of now I don't see how it could be possible — esp. if >>>> stdlib packages were to use it. >>>> >>>> I'm curious what are your thoughts on whether this would be a good >>>> idea? Do you see some problems with that? Do you think it could be done >>>> outside standard library? >>>> >>>> /Mateusz. >>>> >>>> -- >>>> 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. >>>> >>> >>> >> > -- 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.
