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

    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 
What about isDirectory() ???
That *must* return boolean and possibly throw an exception?


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