To try it out ... catch your own IOException and throw as a
RuntimeException?
If it is not too bad we should make a proposal to review the definition of
next and hasNext and how to handle RuntimeExceptions.
On Fri, May 8, 2020 at 7:37 PM Jim Hughes <jhug...@ccri.com> wrote:
> Hi Jody,
>
> Yeah, this implementation is very locked down:).
>
> We don't use the ContentDataStore API; GeoMesa isn't introducing this
> class into the mix. GeoServer is doing the wrapping... One of the classes
> designed to bring along FeatureTypeInfo uses the DefaultFeatureCollection
> and it delegates to this. (If I recall correctly from debugging earlier.)
>
> Thoughts?
>
> Cheers,
>
> Jim
> On 5/8/2020 6:59 PM, Jody Garnett wrote:
>
> That is tricky, since this wrapper is trying to mimic iterator behaviour.
> The intension was to wrap any IOExceptions in runtime exceptions (such as
> NoSuchElementException() ) in the event their are any IO problems, and help
> code that was previously based on in memory collections transition to
> streaming IO.
>
> The FeatureReaderIterator method in question is here:
>
> * public boolean hasNext() {*
> * try {*
> * if (reader == null) return false;*
> * if (reader.hasNext()) {*
> * return true;*
> * } else {*
> * // auto close because we don't trust*
> * // client code to call closed :-)*
> * close();*
> * return false;*
> * }*
> * } catch (Exception e) {*
> * close();*
> * return false; // failure sounds like lack of next to me*
> * }*
> * }*
>
>
> Q: How does it do if you modify the catch( Exception e) block above to
> throw a runtime exception. I can kind of see why the default implementation
> does not take this approach. I tried going back in git / svn history but I
> cannot find an earlier implementation to use as a reference.
>
> This implementation looks very locked down and I cannot see a way around
> with it in place. You would need to modify the above code (which I would
> support) or introduce your own wrapper (override ContentDataStore
> superclass).
>
> --
> Jody Garnett
>
>
> On Fri, 8 May 2020 at 14:58, Jim Hughes <jhug...@ccri.com> wrote:
>
>> Hi all,
>>
>> I'm digging into error handling around timeouts for a GeoTools DataStore
>> (the various GeoMesa DataStore implementations). In GeoServer, the
>> GeoMesa FeatureReader ends up being wrapped by the GeoTools
>> FeatureReaderIterator.
>>
>> This class swallows exceptions from close() and hasNext(). Are there
>> examples of getting Exceptions through this class? I tried a few
>> things, and stuck on how pass information (such as an exception
>> indicating that a query had a problem on the remote server or that the
>> query reached its timeout) through this class.
>>
>> Thoughts?
>>
>> Cheers,
>>
>> Jim
>>
>> 1.
>>
>> https://github.com/geotools/geotools/blob/master/modules/library/main/src/main/java/org/geotools/feature/FeatureReaderIterator.java
>>
>>
>>
>> _______________________________________________
>> GeoTools-Devel mailing list
>> GeoTools-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
> --
--
Jody Garnett
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
