Quoting [sbrandt@cct.lsu.edu] (Jun 22 2006):
Quoting Andre Merzky
: There is a single case where we can't remove it (well, I found that one only at least): opening a file with with the flags (Create | Excl). That MUST raise an error, otherwise the flag would make no sense.
Yes, but if it really is the only place then maybe this is really a WriteError, or some subclass thereof.
BTW, are the names of these exceptions still debatable? Because having the name "Error" in a Java exception that is not a subclass of Error is awkward. It would be nicer if we could call it something else like "WriteException".
That should be up to the language binding I think. Other languages don't have exceptions at all (C), or totally different error reporting mechanisms (Perl). Important is IMHO that the semantics stays the same over the various language bindings, as far as possible...
As for mkdir, we tried to stay close to what users know from command line, and from POSIX/libc, which both return an error if the dir exists.
I think it depends. One could argue that if we want to mimic POSIX/libc then this should show up as a return code and not an exception. Posix does not force you to clutter your code with handling this case every time you call mkdir().
We tried to minimize the number of return codes though, but you have a good point here I think. However, the same argument should then be applied to all methods - right now only a few methods indicate error conditions via return values (read/write beeing a notable example). Andre.
I could see throwing an exception of some sort if, at the conslusion of the call to mkdir(), the directory did not exist.
Cheers, Steve
-- "So much time, so little to do..." -- Garfield