Sam Dean is paranoid. Well, about error handling, anyway.
He favours always initialising error pointers to nil for safety's sake. I personally prefer not to, and leave mine initialised as garbage. My brain sees that declaration as unusual and so takes a little more care to notice why.
I appreciate it's not for everyone. Either way though, I am aware of a bug in the Cocoa frameworks where you absolutely must pre-set the error to nil, otherwise you could be in for a nasty crash. You may be unsurprised to learn this is related to sandboxing.
OS X 10.7.3 introduced security-scoped bookmarks. In my testing I found that either of these calls could do the wrong thing:
On 10.7.3, I have seen (with mine own two eyes!), under certain circumstances, both of these calls return nil and not touch the error pointer. Thus you go to present the error, and it crashes because it's garbage, rather than a real error or even nil.
I've also seen the internals of these methods try to dereference the error pointer themselves and crash doing so.
As far as I can tell this is fixed in 10.8, or maybe even a 10.7.x release, but I can't be sure — Apple haven't mentioned it in the docs or a release note so far — so you probably ought to treat it as if the problem still stands. Besides, if you're targeting 10.7, this bug is already in the wild for some customers; you have to live with it.