Reading from it and handling the errors is left to user. 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.
