| |||||||||||||
Google's new "Go" languageGoogle's new "Go" languagePosted Nov 11, 2009 19:11 UTC (Wed) by zorro (subscriber, #45643)In reply to: Google's new "Go" language by nix Parent article: Google's new "Go" language
The C++ philosophy is that if the construction of an object succeeds, then
the destruction of the object can not fail. This makes perfect sense to me. When you have allocated a piece of memory, there should be no reason why it cannot be deallocated. When you have opened a file, there should be no reason why it cannot be closed. When you have acquired a mutex, there should be no reason why it cannot be released. In other words, there should never be a problem cleaning things up.
(Log in to post comments)
Google's new "Go" language Posted Nov 11, 2009 20:00 UTC (Wed) by rks (guest, #55908) [Link]
but close(2) does a lot more than just closing a file, it may also report errors for earlier writes. If this happens in a destructor, there is no good way to to handle this: there is no return value, and you cannot throw an exception.
Google's new "Go" language Posted Nov 11, 2009 21:30 UTC (Wed) by magila (subscriber, #49627) [Link]
Yes, in that case you are forced to make an explicit close() call before the destructor runs. That is the price you pay for inflicting such brain damaged behavior in the name of performance.
Google's new "Go" language Posted Nov 11, 2009 21:46 UTC (Wed) by nix (subscriber, #2304) [Link]
There are other hacky workarounds: you could remember what went wrong in
some other data structure.
But that doesn't fix the fact that they *are* hacks (and this is really
Google's new "Go" language Posted Nov 13, 2009 12:29 UTC (Fri) by ibukanov (subscriber, #3942) [Link]
> Go has neither destructors
Go has the defer statement that defers execution of some function until the caller is about to return, http://golang.org/doc/go_spec.html#Defer_statements. They are much more flexible than C++ destructors.
Google's new "Go" language Posted Nov 13, 2009 19:59 UTC (Fri) by nix (subscriber, #2304) [Link]
Yes indeed, but they're not destructors, so don't have the same problems.
(They're really neat; like a debugger feature usable in real life.)
Google's new "Go" language Posted Nov 12, 2009 7:13 UTC (Thu) by PO8 (guest, #41661) [Link] "When you have opened a file, there should be no reason why it cannot be closed." Safely closed? Really?
Google's new "Go" language Posted Nov 12, 2009 7:17 UTC (Thu) by PO8 (guest, #41661) [Link]
Oops. Too late.
Note, though, that a file might be unclosable because its underlying removable media has gone temporarily missing since the last write, and filesystem metadata needs to be updated. In this case, it's hard to blame the language, the OS, or anyone else for wanting to raise an exception during the destruction of the fd. It might or might not be nice if all hardware physically locked removable media while it was in use, but obviously this isn't the normal case in 2009.
Google's new "Go" language Posted Nov 12, 2009 7:46 UTC (Thu) by michaeljt (subscriber, #39183) [Link]
I will play the devil's advocate here, and say that a file can always (except see below...) be safely closed once it has been opened. It is just unwritten data which may not be safe :) But the job of a destructor is not to write unwritten data, it is to close/destroy resources. Where I work, we have a policy for dealing with this sort of thing that an object should also have an "uninit" method if it needs to do more advanced cleanup than simple destruction, which the owner is responsible for calling in time.
And of course, to my mind, failing to write because the user removed a removable medium is not an exceptional case - it is something that should be expected and handled. An exceptional case, in which the file cannot be safely closed, might be that the file's descriptor structures in memory have been corrupted or something on those lines - something that is not expected, and that we can't think of a reasonable way of handling.
|
|||||||||||||