I don't think it's inherently *un*idiomatic to return a cleanup function. But in this case, it seems unnecessarily complicated (and buggy).
On Thu, Mar 4, 2021 at 2:19 PM Christian von Kietzell < chris...@vonkietzell.de> wrote: > - doSomething doesn't care whether the output is a file or a buffer or > os.Stdout, so it should just get an io.Writer. > I definitely agree with this. > - The cleanup work for using os.Stdout (or a buffer in tests) is > different than for *os.File. > - Who's responsible for doing that work? If I return *os.File directly > from getFile(), there's an implicit assumption that the file needs to be > closed by the caller. But what if it's os.Stdout? > One possibility that we need to mention is that it would be possible to return a new file, connected to stdout, for example by using syscall.Dup <https://golang.org/pkg/syscall/#Dup>. You could also wrap `os.Stdout` in a new type, with a no-op `Close` method. > - The alternative of putting all that in run() is kinda ugly because > run() potentially has to do a lot more. > Nevertheless, personally, I think it's the right choice, ultimately. A potential problem I see? The error from os.File.Close() is never > checked, neither is the error from bufio.Writer.Flush(). In this small > example that wouldn't bother me because it means the program ends > anyway. But in other cases it might become more of a problem. > Yes, at the very least, your cleanup function should return an `error`. That `error` might just be statically `nil`, but the failure when flushing/closing (FTR, I don't think you need to flush, if you close the file anyway) should definitely be handled some way. That's why I think your code as-is is actually buggy. "The program will end anyway" isn't a good reason to silently leave a corrupt file behind. So, I would probably be fine accepting this in a code-review (as long as the error is checked) but I would prefer to just inline the function into `run`. > What do you think? > > Kind regards, > Chris > > -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/7baf0ec35696fc5501dfbe6ce8f161f8%40vonkietzell.de > . > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfEb_%3DrNCkVBfWodMQ7B-FhBrcGBAo82G3XsFUTWGcPETQ%40mail.gmail.com.
