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
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
So Ben checked exceptions in Java have there problems; as a library for the
Java language it is not our problem to code around java weakness?
It looks like we have a clear group preference for:
- unchecked exception now for feature iterator next() and hasNext() methods
For me it is even mon
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
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 +
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 colle
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
> Featur
-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
happ
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.
On 25/06/10 13:59, Andrea Aime wrote:
> 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 al
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
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
> PersistenceTech
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. SQL
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. c
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 abou
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
PersistenceTechnologyThatHasNotYetBeenInventedCheckedExce
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 detai
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.
>>> SimpleFeatureRea
>> 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;
>> t
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() an
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 ex
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, gr
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 m
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 space,
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 hit
25 matches
Mail list logo
