I replied on the issue; in short, if the proposal gets dismissed, I'll take my chances at creating a third-party package with some super simple API, and then try advertising it here, on reddit, and maybe to other packages.
On Thu, Apr 5, 2018 at 2:14 PM, Axel Wagner <axel.wagner...@googlemail.com> wrote: > 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.
