Is there a pattern for dealing with non-memory resources on cleaning up an ObjC object?

Question

It's usual for objects which have some state related to a non-memory resource to provide a method for explicitly 'finishing' with that resource. Is there a preferred common practice for dealing with the case where an object deallocation is attempted while still in the "using my resource" state? I have seen a couple of different approaches:

1. log that the programmer made a mistake and tell them how to debug it (NSLock does that)
2. let the caller choose whether the resource is managed by the caller or relinquished on deallocation (e.g. NSFileHandle)
3. raise an exception if the object is not in an expected final state, i.e. assert that the programmer isn't going to use my object in that way
4. always clean up on the way out.

The GC docs confirm that managing other resources alongside memory management is A Bad Idea and (yet) provide an example of doing 4, albeit with caveats. So has anyone "chosen" an approach to always follow?

Answer 1

Since most of the Cocoa framework objects predate garbage collection, you can't make the assumption that NSFileHandle, for example, is doing it the best way. I think this problem is one of many where we'd like to have one pattern to follow for every scenario and save us the trouble of making a choice. Unfortunately, I don't think that's possible; you're going to have to determine what's best on a case-by-case basis.

Here are reasons to choose any of your options:

1. If automatic cleanup is reasonably safe but the program really ought to do it manually.
2. If you're writing a library and the resource may or may not be owned by your object.
3. If automatic cleanup is not possible or somehow risky.
4. If automatic cleanup is trivial and not worth bothering anybody to do it manually.