That's my point though. In a more OO language, an object would know how to clean itself up. This isn't even garbage collecting, in C# the IL will be written in the compiler to automatically call the Dispose method at the end of the using block. In this case, all you have is log an error and return throw an exception.

That completely removes the risk of missing adding cleanup code. Additionally, your example relies on the developer remembering to assign the return code correctly.

I personally, don't have a problem with your code. If you want to use single returns, go for it. On the other hand, you haven't convinced me that single returns should be considered best practice. I don't need to load the code up and debug through the code to understand it. At this point, the argument either way is more about style than substance.

As far as throwing exceptions, I agree that it's overused. I think you should only through exceptions because of unexpected errors. If there is an error because of bad input, a result should be returned to the caller that describes what is wrong with the input. For example, if the file designated by the filename couldn't be opened because it doesn't exist, that should be a return code not a thrown exception.