InputFeatureStream :
I guessed you wished a stream, but a Reader could be better.
Or anything else. What would you prefer ?
Control the values :
How can I check if a shapefile content is correct ? Do you have some basic
controls to suggest ?
Shapefile - Dabase
Currently one MappedByteBuffer reads a shapefile,
while another one reads the Database.
The first record of the shapefile matches the first record of the database,
the second record of the shapefile matches the second record of the
database.
is it always true ?
SQLException and DataStoreException :
I agree that top level function should limit themselves to SQLException,
and this would allow the caller who wants to specfically catch the
exception subclass he wants in case he really wants to.
But if you convert an SQLException to a DataStoreException :
throw new DataStoreException(sqlException.getMessage(), sqlException);
I fear the caller will have no way to react programmatically to the real
cause of a trouble. To allow programmer continuing to react to that, we
should set vendor codes in SQLException subclasses and DataStoreException.
Else, only the message will carry the cause of the trouble, and no code can
do that :
if (e.getMessage().contains("No more record")) {
...
}
else {
if (e.getMessage().contains("connection closed")) {
...
}
}
I ensured to give a chance to the caller to react to any specific problem
he wishes, and to avoid seeing them by doing a simple
catch(SQLException e) that globlalize all. If you force the developpers to
summarize to a single DatastoreException, you will loose this ability.
Marc.
2015-01-05 9:07 GMT+01:00 Martin Desruisseaux <
[email protected]>:
> Hello Marc
>
> Le 04/01/15 22:03, Marc Le Bihan a écrit :
> > The Shapefile class could disappear. The way to read Features from a
> shapefile is now :
> >
> > InputFeatureStream is = new InputFeatureStream(shapeFile,
> databaseFile); // Shapefile (.shp) and Database (.dbf) files.
> > Feature feature = is.readFeature(); // null is returned when the end of
> the shapefile / database are reached.
>
> Why InputFeatureStream extends java.io.InputStream? What are the meaning
> of the bytes stream? In the source code, the method reading bytes just
> throw an UnsupportedOperationException, so why extending InputStream at
> all if almost all their methods are unsupported?
>
>
> > 1) What control can I do on values red on shapefile (not the database
> part, but the shapefile part) to ensure that I am not reading stupid things
> ?
>
> Could you give an example of what you mean?
>
>
> > 2) Can we guess Shapefile entry #4 = Record #4 in the Database
>
> I have not yet read the Shapefile specification. What are the difference
> between an entry and a record?
>
>
> > 4) Shall I put all the exceptions in a public package instead of their
> internal package ? I think it would be better.
>
> We could put some of them in an "org.apache.sis.storage.shapefile.sql"
> package. However those exceptions are specific to the SIS implementation
> of DBase3. Other JDBC driver never throw those exceptions. Consequently,
> any generic code designed for arbitrary database (PostgreSQL, Oracle,
> etc.) can not depend on those exceptions. Since we try to write Apache
> SIS for generic databases, this means that even SIS would not try to
> catch those exceptions.
>
> Furthermore all those exceptions extends SQLException, which are not the
> kind of exception that we would handle most of the time. The
> higher-level API is rather DataStore, which define a DataStoreException.
> The SQLException and IOException are lower level mechanic, which would
> appear in the "caused by" property of DataStoreException.
>
> Given the above, I do not expect any "catch" clause for those exceptions
> outside the Shapefile module. So what would be the use case for making
> those exceptions public?
>
> Martin
>
>
