Jody Garnett ha scritto:
On 25/06/2010, at 5:47 PM, Andrea Aime wrote:
+1 on adding a similar chained runtime exception to iterators,
better than nothing.
I will try and cook up a patch / proposal.
However I have a dreaded insight; for our use case of using a while
loop: you asked how
christian.muel...@nvoe.at ha scritto:
A big +1 one for this proposal, having our own
FeatureAccessException with a Constructor
FeatureAccessException(Exception ex).
We actually always had that, DataSourceException, but for
some reason people decided not to use it anymore.
Honestly no
Hy Ben, I am also bored with checked exceptions, but how to handle
error situations ? Mostly, and exception is raised during IO. If I
look at the java sdk, it is very unlucky that you have to catch an
IOException if you work with Byte Streams. This is a trade off of the
java stream design.
-1 ** (2*n - 1) for me (where n is a natural number).
Now, what about an SQLException with an IOException as its cause? Or
vice versa?
In my experience, developers designing their own exception hierarchy is
a bad sign ...
If this news exception is checked the first thing that is going to
On 25/06/10 14:06, christian.muel...@nvoe.at wrote:
I see to possibilities
1) Having our own checked exceptions
2) Having no checked exceptions and use runtime exceptions.
I like (2). How about RuntimeException?
For 2) it would be nice to have our own runtime exception class like
Ben Caradoc-Davies ha scritto:
I am happy for libraries to throw exceptions, I just dislike the
language micromanaging my handling of them.
See this comment from Florence:
hmm.. may be or may be it is related to issue ben just raised
regarding no ioexception being catch in feature
We already have DataSourceException that meets this need Christian.
it is a checked exception however; I think what Ben is getting at is that we
should:
- make an unchecked exception
- add it to our library where needed
Jody
On 25/06/2010, at 3:51 PM, christian.muel...@nvoe.at wrote:
A big
Jody Garnett ha scritto:
We already have DataSourceException that meets this need Christian.
it is a checked exception however; I think what Ben is getting at is that we
should:
- make an unchecked exception
- add it to our library where needed
+1 on adding a similar chained runtime
On 25/06/2010, at 5:47 PM, Andrea Aime wrote:
+1 on adding a similar chained runtime exception to iterators, better than
nothing.
I will try and cook up a patch / proposal.
However I have a dreaded insight; for our use case of using a while loop: you
asked how often people need to do a try
Hi,
looking at the feature collection and feature iterators interfaces again
I'm seeing another serious design mistake: they don't throw IOException
anywhere.
This is not sane imho, grabbing a collection, getting the feature
iterator, iterating over the features are all occasions in which
you
Your are right here, but
1) This breaks the client code
2) The implemeters of FeatureCollection currently throw a runtime
exception in such situations (seen in ContentFeatureCollection), you
have to rewrite these methods too.
The biggest question is 1) regarding to applications in user
Inside Joke: This could be Bring Back FeatureReader
On 24/06/2010, at 11:59 PM, Andrea Aime wrote:
Hi,
looking at the feature collection and feature iterators interfaces again
I'm seeing another serious design mistake: they don't throw IOException
anywhere.
This is not sane imho, grabbing
Around in circles we go :-P
FeatureReader is like an iterator that throws IOExceptions ... and users hated
it.
But yes I will consider it - we are trying for a much stronger sense of YOUR
ARE DOING IO BE CAREFUL and thrown exceptions really scream that to people
using a project. So although
Jody Garnett ha scritto:
Around in circles we go :-P
FeatureReader is like an iterator that throws IOExceptions ... and users
hated it.
Who besides James hated it? ;-)
But yes I will consider it - we are trying for a much stronger sense of
YOUR ARE DOING IO BE CAREFUL and thrown
I agree. In my opinion not just sticking with FeatureReader and
introducing FeatureIterator and Iterator really messed up the api.
What do you mean by bring back feature reader. Did it go away some how?
If we are going to fix the feature collection interface we could
deprecate iterator() and
Around in circles we go :-P
FeatureReader is like an iterator that throws IOExceptions ... and users
hated it.
Who besides James hated it? ;-)
Not sure I was too shy at the time; I do remember hating explaining it to
people repeatedly.
SimpleFeatureReader reader = null;
try {
Jody Garnett ha scritto:
Around in circles we go :-P FeatureReader is like an iterator
that throws IOExceptions ... and users hated it.
Who besides James hated it? ;-)
Not sure I was too shy at the time; I do remember hating explaining
it to people repeatedly.
SimpleFeatureReader reader =
On 24/06/10 21:59, Andrea Aime wrote:
looking at the feature collection and feature iterators interfaces again
I'm seeing another serious design mistake: they don't throw IOException
anywhere.
I am a card-carrying checked exception hater. They have the effect of
leaking implementation details
On 24/06/10 21:59, Andrea Aime wrote:
looking at the feature collection and feature iterators interfaces again
I'm seeing another serious design mistake: they don't throw IOException
anywhere.
They should also throw SQLException. And
On 25 June 2010 14:01, Ben Caradoc-Davies wrote:
[I'm going to hide under my desk until Andrea has cooled down.]
Don't imagine you'll be safe there Ben. A few weeks ago Andrea was on
the verge of nuking Sydney because of something Jody said.
This might be a dumb question (I don't know much
On 25/06/10 13:11, Michael Bedward wrote:
This might be a dumb question (I don't know much about Exception
handling) but isn't the least worst approach to the problem of
'leaking' implementation into interface to wrap IOException,
SQLException etc into some GeoTools exception class, e.g.
A big +1 one for this proposal, having our own
FeatureAccessException with a Constructor
FeatureAccessException(Exception ex).
The IOException drives me crazy, because in Java 5 there is no
constructor IOException(Exception ex), in Java 6 there is.
Getting a backend exception (e. g.
Ben Caradoc-Davies ha scritto:
On 24/06/10 21:59, Andrea Aime wrote:
looking at the feature collection and feature iterators interfaces again
I'm seeing another serious design mistake: they don't throw IOException
anywhere.
They should also throw SQLException. And
23 matches
Mail list logo
