cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ricardo Rocha <rica...@apache.org>
Subject Re: A Suggestion for Cocoon2 Store
Date Sun, 26 Mar 2000 01:12:41 GMT
Ricardo Rocha wrote:
> Interface org.apache.cocoon.components.Store defines
> methods store(), hold() and remove() as void, not
> throwing any exception.
> Since persistent stores (e.g. a filesystem-based store)
> may generate errors (e.g. IOException) during these
> operations, it makes sense to make the above methods
> return boolean so that client classes are able to test
> whether the operation actually succeeded even in
> the absence of an exception.
> Note that this is the way java.io.File handles operations
> such as delete(), createNewFile() or mkdirs()...
> What do you guys think?

Kevin Burton wrote:
> -1.  Don't return boolean just throw an Exception.  This isn't C and it
> is proven that eventually people don't catch these.  
> Throw a StoreException or something.

Hmmm... using boolean instead of throwing an exception is a
recurrent design pattern in collection operations. For instance,
Hashtable.remove() returns null for non-existent keys and
Vector.removeElement() returns boolean instead of throwing
an exception.

While I agree with Kevin that return values may be easily
ignored (thus leading to a careless programming style) it
appears to me it's also true that the semantics of failure for
this particular kind of operation isn't that of a "true" error
condition...

Mime
View raw message