>>Moreover, who else agrees that __finally blocks are ugly and extremely >>error prone and difficult to maintain? What sort of solution could we use >>to allow what C++ developers know as a destructor to do automatic cleanup?
>I don't agree, I love them! Much better than writing those stupid C++ >object wrappers with one-line dtors just because some file handle needs >closing or whatever. You never used <fstream> or CFile? Granted, the __finally blocks are a nice addition, but they are a poor replacement for an object that cleans itself up correctly and deterministically. >I suspect you're stuck in a C++ paradigm where you feel you have to design >objects that automatically eradicate themselves as soon as they get out of >scope. That's absolutely not the .NET paradigm. The finally block exists >for the same reason as the IDispose pattern, namely to provide a solution >for those _rare and exceptional_ circumstances when you have to do some >deterministic cleanup at the end of a method or of an object's lifetime. >Unlike unmanaged C++, you absolutely don't have to do this all the time. In >fact, you shouldn't. Let the garbage collector do most of the clean-up for you! "_rare and exceptional_": Elaborate how the use of file handles, database handles, OS handles, and COM objects is rare and exceptional??? All of these require deterministic finalization. It is just not acceptable for robust code to release handles whenever the garbage collector feels like it. If, when reading a file, an error occurs, the user would expect that file to be closed. Are we going to go back to the day when we ask the user to shutdown the application to make sure that files get closed? >>By exception safety I mean, the state of the system is not left in a half >>baked state when an exception occurs. Destructors (and IDispose) are >>essential in this regard, unless you want to litter your code with >>unmanageable, error prone __finally blocks. >No, you are completely wrong here. .NET does not work like unmanaged C++, >you don't have to clean up everything yourself. That's what the garbage >collector is for. You do _not_ have the responsibility to leave the system >in a well-defined state in the face of exceptions -- the system takes care >of that automatically. This is just not true. Keeping the system in a well-defined state is more than just releasing resources. It also includes whether or not objects are half-constructed, whether operations are left half-done. Optimally, you would like to have commit/rollback behavior in the face of exceptions. The .NET garbage collector provides little support for this type of exception safety. See basic and strong exception guarantees. http://www.boost.org/more/generic_exception_safety.html >>Am I smoking something, or does anyone else agree that there are some very >>open ended issues here. :-) >I can't really tell if you're smoking anything, I suspect you just need to >read a good .NET introduction and get those C++ programming patterns out of >your mind. :-) The standard book on the .NET Framework is Jeffrey >Richter's "Applied Microsoft .NET Framework Programming" (Microsoft Press). >It should clear up all the questions you have. I disagree. I think the OP (original poster) reflects common concerns regarding the garbage collector. These issues have also been talked to death already in the DOTNET group. Search for garbage collector in the DOTNET group. Consider also that Chris Sells is trying to get deterministic finalization built in on top of the .NET model by adding reference counting. That would be the best of both worlds. Johan You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
