[jcifs] SmbException Supercedes boolean?
James Nord
teilo at teilo.net
Tue Oct 30 06:50:25 EST 2001
Well I would go the other way and return boolean...
Better design as exceptions should not be used to test if an opperation
was succesfull...
Makes for cleaner code/programming structure (if used correctly)
(IMHO which goes 100% against the other reply ;-) )
Also - its what the java libraries do...
mkdir()
public abstract boolean mkdir()
Creates a directory, the pathname of which is specified by this
XFileAccessor object.
Returns true if the directory could be created; false otherwise.
Just my religion...
Besides, does it harm to return boolean? It may come a time where its
benifical to the code.
Is it not possible to not make a directory/file etc.. and not throw a
exception?
What about isDirectory() ???
That *must* return boolean and possibly throw an exception?
/James
Rob Wygand wrote:
> Mike,
>
> I recently encountered this, and I think it's best to return void. We
> had some functions that returned boolean, but always threw exceptions
> on errors, and what we found was that some people caught the
> exceptions and did nothing with them, only using the return value of
> the function. This, obviously, caused confusion and errors. It's just
> a much clearer contract when void is returned.
>
> rjw
>
> Allen, Michael B (RSCH) wrote:
>
>> Does anyone have an opinion as to whether or not SmbFile methods should
>> return boolean now that many throw SmbException? For example, 0.5.1 has:
>>
>> public boolean mkdir()
>>
>> which looks like it's java.io.File counterpart and returns true if
>> the directory was
>> successfully created and false otherwise. For 0.6.0 I was planning on
>> just
>> adding the throws to this like:
>>
>> public boolean mkdir() throws SmbException
>>
>> but returning boolean is rather pointless given that any kind of
>> failure provokes
>> an SmbException. I don't know of any other context that might make
>> use of
>> boolean. I think this should just be:
>>
>> public void mkdir() throws SmbException
>>
>> Any opinions? Obviously this is pretty important because it's
>> undoubtledly
>> going to break code so I'd rather only do this once.
>>
>> Mike
>>
>>
>
>
More information about the jcifs
mailing list