4 ms·
Sorry, but for me its not a great method of releasing resources. I tend to (for example) open a connection in one function, do something with it in another fun
by dana321 8y ago
Sorry, but for me its not a great method of releasing resources.
I tend to (for example) open a connection in one function, do something with it in another function, close it in another. I'm not writing traditional go programs, i wrap things in an api.
- echlebek 8y agoSounds like that practice would make resource lifetimes hard to reason about. And without defer, you don't have the opportunity to clean up resources if a goroutine panics.
- kazinator 8y agoThe higher level procedure which uses these three functions could use defer to ensure that the closing function is called.
- dana321 8y agoI would have to re-arrange my call stack so that the read or write functions would be inside the open statement, then it would close it at the end anyway so its kind of pointless for my uses. I try and totally avoid panics and never throw them unless its at some initial parser stage. But this is made me rethink the structure of how some of my tags operate in my interpreter / transpiler.