[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSSearchPathForDirectoriesInDomains and non-existing directories

From: Sheldon Gill
Subject: Re: NSSearchPathForDirectoriesInDomains and non-existing directories
Date: Tue, 25 Oct 2005 07:57:48 +0800
User-agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)

Andriy Gapon wrote:
Let me shoot the question first - what is the rationale behind
NSSearchPathForDirectoriesInDomains not returning directory name if the
directory does not exist ? Esp. so if NSUserDomainMask is used ?

This is the way the function was defined to work a long time ago. In other words, it behaves as specified.

The idea in general terms is that you are asking for a location. If that location doesn't exist, it returns <nil> rather than an exception. The location may not exist because you're running on an old or new version where it doesn't exist anymore. Things change.

Calling code is supposed to know and respect this.

In my opinion what NSSearchPathForDirectoriesInDomains() does now is
incorrect. I don't have an opportunity to verify how this function
behaves in original NeXTStep or how it behaves in OS X framework, but I
think GNUstep behavior is unreasonable.

I see two possible ways of improving NSSearchPathForDirectoriesInDomains():

1. just return the names and let calling code worry if the directories
actually exist
2. try to create non-existing directories in the list and only if that
fails that remove them from the list

I personally am torn between simplicity and elegance of #1 and
user-friendliness of #2.

I think you've mis-diagnosed the behaviour problem. It isn't in NSSearchPath() but rather the calling code. Creation of a path isn't and shouldn't be the responsibility of NSSearchPath(). That needs to be handled elsewhere. Generally it is, by the way.

There is some sense in (1) but the question arises: "what do you do when the specified directory doesn't make sense on the current system?" You'd end up needing to handle an exception or error return anyway.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]