My dear friend st ov,
I think you better have a very compeling reason NOT to use defer, because
every Go programmer on Earth will expect the defer pattern in such
scenarios. By avoiding defer, code becomes different than the norm and so,
harder to understand. The poor reader will keep wondering what reasons you
had to do things differently.
On Wednesday, May 10, 2017 at 12:55:35 PM UTC-3, st ov wrote:
>
> Most examples of opening and closing a file have both calls in the same
> function
>
> func DoFileStuff() {
> file, _ := os.Open("file")
> defer file.Close()
>
> // do stuff with file
> }
>
> This makes sure any open file is closed.
> But how common is it to separate that logic into functions?
> Should this be absolutely avoided as it could result in a file left open?
>
>
> func DoStuff(f string) {
> file := OpenFile(f)
>
> // call DoingStuff for some practical reason
> DoingStuff(file)
> }
>
> func DoingStuff(f *File) {
> // do stuff on file
> Cleanup(f)
> }
>
> func OpenFile(f string) *File {
> file, _ := os.Open(f)
> return file
> }
>
> func Cleanup(f *File) {
> f.Close()
> }
>
>
>
>
--
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.
