On May 7, 2:39 pm, dizzy <di...@[EMAIL PROTECTED]
> wrote:
> James Kanze wrote:
> > That's just overloading and a default argument. (For that
> > matter, you could argue that the overloading isn't necessary,
> > since a char const* converts implicitly to an std::string.)
> Correct, the char const* uses are very few to worth those versions.
> > On the other hand, you don't want to tie the modes down that
> > much to the underlying OS. I use symbolic constants, open and
> > closed: the default is closed (which maps to 0700 under Posix).
> > open maps to 0775, but you could easily define more (probably
> > accepting that some will end up mapping to the same thing on
> > some other systems).
> Good idea, in my case the code is to be used only on POSIX
> systems but I'll keep that in mind because I too like to write
> ****table code even when not required.
> > There are really only two options: you re****t an error if the
> > creation fails, or you don't, if the directory already exists.
> > Logically, it's two different operations: createDirectory(), and
> > ensurePath().
> Good catch, indeed these are 2 separate operations I now
> realise. Although your choice of name is slightly bad, as you
> realised one thing is ensurePath() that is more similar to
> mkdir -p and another would be say an "ensureDirectory()" or
> something like that.
To tell the truth, I don't remember where I got the name from.
But the "ensure" is the significant part: if the directory
already exists, then it's not an error. Whereas it is with
createDirectory.
> > You might also want to consider a more elaborate error code,
> > with different types of error conditions.
> Could you elaborate?
Some client code might want to know why the operation failed:
insufficient rights, hardware problem, missing sub-directory (in
the case of createDirectory), etc.
> > For something this low level, the only really appropriate
> > way to re****t an error is with a return code. If the client
> > code wants an exception, it can wrap the function (and if it
> > really wants to ignore any errors, it can do that as well).
> It does appear tho that all projects that will use this code
> will prefer usually the throw version (except some other low
> level code which usually builds upon nothrow versions) which
> is why I thought I need both.
The most frequent use in my code is to create a subdirectory for
tem****aries. If this fails, I abort.
In general, with such functions, it's a difficult call. But in
general, any time it the issue is unsure, I use a return code;
it's very, very easy to convert a return code into an exception
(or the equivalent of an assertion failure) if that's what is
needed; converting an exception into a return code is somewhat
more difficult (and converting an abort into a return code is,
of course, completely impossible). And of course, you're not
calling this function hundreds of places in an application, so
it's not as if wrapping it were a big deal.
Another alternative that I played with in the past is a user
defined callback. The callback normally does nothing, and the
return code is returned, but it could throw an exception. In
the end, I found this too much complication, particularly for
the immediate clients, who didn't necessarily know exactly what
to expect.
--
James Kanze (GABI Software) email:james.kanze@[EMAIL PROTECTED]
en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
|
