Hi,
every day I build Geotools, and every day I get this:
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
No versions are presen
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
On 24/06/10 20:53, christian.muel...@nvoe.at wrote:
> H i Ben, this discussion stopped without a result. What are your next steps ?
No, it stopped with the result that my proposal to avoid HashMap was
rejected.
Blame has been fairly laid at the feet of anyone who expects stable
iteration order
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
H i Ben, this discussion stopped without a result. What are your next steps ?
This message was sent using IMP, the Internet Messaging Program.
--
ThinkGe
christian.muel...@nvoe.at ha scritto:
> Sorry, some confusion in my brain today.
>
> Rereading your mails I see that your sponsor wants two have 2 different
> param paths. I think this is the solution I voted for. ?
It is
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert serv
Sorry, some confusion in my brain today.
Rereading your mails I see that your sponsor wants two have 2
different param paths. I think this is the solution I voted for. ?
If it is, forget my proposal, I assumed vt AND sld use EnvFunction.
Sorry for the confusion.
Quoting Andrea Aime :
> c
christian.muel...@nvoe.at ha scritto:
> Hmm, one parameter for layout AND data access ?
>
> However, looking at geotools as a library, it is very "unlucky" to
> introduce a new parameter passing mechanism. This is surly not what a
> developer expects and will cause confusion. And one has to t
Hmm, one parameter for layout AND data access ?
However, looking at geotools as a library, it is very "unlucky" to
introduce a new parameter passing mechanism. This is surly not what a
developer expects and will cause confusion. And one has to take care
to clean up all the values in the e
Michael Bedward ha scritto:
> On 23 June 2010 17:21, Andrea Aime wrote:
>> Votes please :-)
>>
>
> I like the env function approach over yet more hints, but I'm probably biased
> :)
Hmmm... the sponsor just told me he wants to have the sld param
expansion and the sql view paths separate so that
28 matches
Mail list logo
