[jcifs] SmbException Supercedes boolean?

[James Nord]

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
>>
>>
>
>