You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Ricardo Rocha <ri...@apache.org> on 2000/03/25 21:21:59 UTC
A Suggestion for Cocoon2 Store
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?
Re: A Suggestion for Cocoon2 Store
Posted by Pierpaolo Fumagalli <pi...@apache.org>.
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?
Good point... Actually the interface was written by Stefano, so,
_IT_IS_NOT_MY_FAULT_ :)
I believe that whenever someone will ever implement it, the interface is
going to change :)
Pier
--
----------------------------------------------------------------------
pier: stable structure erected over water to allow docking of seacraft
<ma...@betaversion.org> <http://www.betaversion.org/~pier/>
----------------------------------------------------------------------
Re: A Suggestion for Cocoon2 Store
Posted by Stefano Mazzocchi <st...@apache.org>.
Ricardo Rocha wrote:
>
> On Sun, 26 Mar 2000, Kevin Burton wrote:
> > Hashtable and Vector are both totally different than this scenario. You
> > are defining the interface and then implementing the interface. Both
> > Hashtable and Vector have no persistence on filesystems/JDBC.
> >
> > I would rather have a harder time building my code and take the extra
> > time when the possibility of the equivalent behavior of an Exception
> > being thrown.
>
> I give up, common sense (i.e. Kevin & Niclas) wins!
>
> Since exceptions must be defined at the interface level
> (org.apache.cocoon.components.store.Store), the existing
> org.apache.cocoon.components.store.MemoryStore
> implementation must be revised accordingly...
>
> Pier, Stefano: do you agree to this?
I agree. +1
Kevin is right, this is no C.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: A Suggestion for Cocoon2 Store
Posted by Ricardo Rocha <ri...@apache.org>.
On Sun, 26 Mar 2000, Kevin Burton wrote:
> Hashtable and Vector are both totally different than this scenario. You
> are defining the interface and then implementing the interface. Both
> Hashtable and Vector have no persistence on filesystems/JDBC.
>
> I would rather have a harder time building my code and take the extra
> time when the possibility of the equivalent behavior of an Exception
> being thrown.
I give up, common sense (i.e. Kevin & Niclas) wins!
Since exceptions must be defined at the interface level
(org.apache.cocoon.components.store.Store), the existing
org.apache.cocoon.components.store.MemoryStore
implementation must be revised accordingly...
Pier, Stefano: do you agree to this?
Re: A Suggestion for Cocoon2 Store
Posted by "Kevin A. Burton" <bu...@relativity.yi.org>.
Ricardo Rocha wrote:
<snip>
> 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...
Hashtable and Vector are both totally different than this scenario. You
are defining the interface and then implementing the interface. Both
Hashtable and Vector have no persistence on filesystems/JDBC.
I would rather have a harder time building my code and take the extra
time when the possibility of the equivalent behavior of an Exception
being thrown.
Kevin
--
Kevin A Burton (burton@apache.org)
http://relativity.yi.org
Message to SUN: "Please Open Source Java!"
"For evil to win is for good men to do nothing."
Re: A Suggestion for Cocoon2 Store
Posted by Ricardo Rocha <ri...@apache.org>.
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...
Re: A Suggestion for Cocoon2 Store
Posted by Donald Ball <ba...@webslingerZ.com>.
On Sun, 26 Mar 2000, Kevin A. Burton wrote:
> Niclas Hedhman wrote:
> <snip>
> > Suggestion, introduce a CocoonException which can wrap (similar to
> > java.lang.reflect.InvocationTargetException) other Exceptions, and have
> > other Cocoon related exceptions to be a subclass thereof.
>
> Oh man. +1024 :)
>
> I talked about this under the Turbine mailing list and the decision was
> that although it is a good idea the were throwing "Exception" in too
> many places and that all new code would use TurbineException. A
> CocoonException is a really good idea.
>
> So maybe:
>
> CocoonException -> StoreException ?
+1
- donald
Re: A Suggestion for Cocoon2 Store
Posted by "Kevin A. Burton" <bu...@relativity.yi.org>.
Niclas Hedhman wrote:
<snip>
> Suggestion, introduce a CocoonException which can wrap (similar to
> java.lang.reflect.InvocationTargetException) other Exceptions, and have
> other Cocoon related exceptions to be a subclass thereof.
Oh man. +1024 :)
I talked about this under the Turbine mailing list and the decision was
that although it is a good idea the were throwing "Exception" in too
many places and that all new code would use TurbineException. A
CocoonException is a really good idea.
So maybe:
CocoonException -> StoreException ?
Kevin
--
Kevin A Burton (burton@apache.org)
http://relativity.yi.org
Message to SUN: "Please Open Source Java!"
"For evil to win is for good men to do nothing."
Re: A Suggestion for Cocoon2 Store
Posted by Niclas Hedhman <ni...@localbar.com>.
"Kevin A. Burton" wrote:
> Stefano Mazzocchi wrote:
> >
> > Ricardo Rocha wrote:
> > >
> > > Interface org.apache.cocoon.components.Store defines
> > > methods store(), hold() and remove() as void, not
> > > throwing any exception.
> >
> > +1
>
> -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.
Agrees with Kevin.
Basis; The mentioned Collections and File is not adequate comparisons.
Exceptions are thrown at non-regular conditions (hence the name) where as
elements not existing in a Collection or files not existing on a delete,
is a regular condition and should use return values.
A checked Exception, preferably a Cocoon exception able to wrap the actual
exception is to be prefered.
Suggestion, introduce a CocoonException which can wrap (similar to
java.lang.reflect.InvocationTargetException) other Exceptions, and have
other Cocoon related exceptions to be a subclass thereof.
Niclas
Re: A Suggestion for Cocoon2 Store
Posted by "Kevin A. Burton" <bu...@relativity.yi.org>.
Stefano Mazzocchi wrote:
>
> 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?
>
> +1
-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.
Kevin
--
Kevin A Burton (burton@apache.org)
http://relativity.yi.org
Message to SUN: "Please Open Source Java!"
"For evil to win is for good men to do nothing."
Re: A Suggestion for Cocoon2 Store
Posted by Stefano Mazzocchi <st...@apache.org>.
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?
+1
Please, consider all the interfaces found in Cocoon2 ready to be
reshaped at need. We do not have any back-compatibility problems... so
let's do them right.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: A Suggestion for Cocoon2 Store
Posted by Mike Engelhart <me...@earthtrip.com>.
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?
+1