Ok. With all this information, I think we cannot release yet the shapefile part of the Apache SIS API. I have to read shx content, handle deleted record correctly.
For DataStoreException, it's ok if subclasses can be created. but at the end, DataStoreException will have subclasses to represent various problems coming from SQL, JPA, other data source causes. In my mind, as long as the exception thrown by methods can summarize to DataStoreException when the caller doesn't want to know more, it's ok. He catches a more specific exception if he really wants too. But at the time he wants, he can : he only has to change the exception name in his catch clause. For stream() : I will study the implementation stream() in JDK 8 Marc. 2015-01-05 10:11 GMT+01:00 Martin Desruisseaux < [email protected]>: > Hello Mark > > Thanks for the reply. > > Le 05/01/15 09:50, Marc LE BIHAN a écrit : > > InputFeatureStream : > > I guessed you wished a stream, but a Reader could be better. > > Or anything else. What would you prefer ? > > I was thinking about java.util.stream (new in JDK8 - but I have some > idea for JDK6/7 compatibilities): > > http://docs.oracle.com/javase/8/docs/api/java/util/stream/Stream.html > > While the Javadoc shows lot of methods, many of them are static or have > default implementation. So the number of methods to implement may not be > so high. > > > > Control the values : > > How can I check if a shapefile content is correct ? Do you have some > basic > > controls to suggest ? > > I'm not sure to understand what we mean by correct. Do we mean checking > if a value read from a Shapefile entry/record is of the expected type? > > > > 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 ? > > I just asked to our Shapefile specialist. He said that not necessarily, > there is a third file with ".shx" extension which make the link between > the database entries and the shapefile entries. > > > > SQLException and DataStoreException : > > (...snip...) > > > > 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. > > SQLException indeed have room for SQL state or vendor code. We could > also define DataStoreException subclasses - we have not done that yet > only because we were waiting for more use case experience. > > I agree with the goal to allow caller to react to the cause of trouble. > The question is: are SQLException subclasses the best way to achieve > this goal if there is no code outside sis-shapefile module would catch > those exceptions? Are the alternatives (SQL state, vendor code, > DataStoreException subclasses) worth to explore? > > Martin > > >
