sis-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "M. Le Bihan (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SIS-189) InvalidDbaseFileFormatException should extend DataStoreException
Date Tue, 08 Dec 2015 04:40:11 GMT

    [ https://issues.apache.org/jira/browse/SIS-189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15046333#comment-15046333
] 

M. Le Bihan commented on SIS-189:
---------------------------------

{color:darkblue}_Wrap the SQL exceptions into DataStoreException using the Throwable.initCause(Throwable)
method or the convenience method. There is no need to create dedicated subclasses of DataSourceException
(we can, but this is not mandatory)._{color}
It's done a Shapefile level.
{{ShapefileNotFoundException}}, {{DbaseFileNotFoundException}}, {{InvalidShapefileFormatException}},
{{InvalidDbaseFileFormatException}}, {{DataStoreQueryException}}, {{DataStoreQueryResultException}}
are all extending {{DataStoreException}}, and their relative {{SQLException}} is in root cause
only.

SQL exceptions are summarized into Data Store exceptions this way :
+Problems having chances to come from the environment :+
{{SQLDbaseFileNotFoundException}} -> {{DbaseFileNotFoundException}}
{{SQLShapefileNotFoundException}} -> {{ShapefileNotFoundException}}

+Problems having chances to come from developer code :+
{{SQLConnectionClosedException}} -> {{DataStoreClosedException}}
{{SQLInvalidStatementException}}, {{SQLIllegalParameterException}}, {{SQLNoSuchFieldException}},
{{SQLUnsupportedParsingFeatureException}}, {{SQLFeatureNotSupportedException}}, {{SQLNoDirectAccessAvailableException}}->
{{DataStoreQueryException}}
{{SQLNotNumericException}} | {{SQLNotDateException}} -> {{DataStoreQueryResultException}}

+Problems depicting flawed files :+
{{SQLInvalidDbaseFileFormatException}} -> {{InvalidDbaseFileFormatException}}

{color:darkblue}Subclasses of DataSourceException{color}
Are mandatory.
Let me give you another explicit name for {{DataSourceException}} in this sample code :

{code:java}try {
... various methods called, using many one or more data stores ...
}
catch(ProblemException e) {
    // What happened ? The program can't be clever here : is there a file missing, a wrong
query done, and what file has the problem ?
   // The only thing the program can do now is a pathetic 
   log.severe(e.getMessage());
   // Because the end user will have to undersand the message alone, the program has no more
way to help him. It dismissed.
}{code}

throwing {{DataStoreException}} is quite the same thing as throwing the core {{java.lang.Exception}}
or having function returning {{Object}} : you planify your program death

In term of Petri net, if before attemting the code part I shown upside you are in state (=place)
E1, and that if case of succes you are in state E2,
+each+ distinct exception thrown represent another +different+ state. An unwished state maybe,
but a state however. You can't say : "_E3, E4, E5 ... E10 states follow on from one of this
specific exception will be resumed to a global E11 state_" that has no well defined existence
and has especially no sense if done automatically without thinking.

Summarizing to a global state disallow the program to attempt catching some exception at various
level of the call stack climb up. What is especially I want a clever program to do !!!! Handle
a troublesome situation (in place of the end-user) in a case a clueless program won't ! This,
just maybe to classify the trouble and send a log to the administrator for files missings
or developers for wrong queries. Loosing the ability to catch specific problems among the
call stack make your program frail. Or at least the end-user believe it : he see a program
that stops for "_almost everything_".

Another reason is that subclasses of {{SQLException}} for a specific problem is that they
are carrying specific data to depict it :
{{SQLIllegalParameterException}} has for additional members :
- the database file that was queried.
- the sql statement that went wrong.
- the parameter name that is illegal.
- its illegal value.

Why ? Because at the time this exception was issued, the API had _all_ this informations available.
So it has to return them to avoid a developer or a DBA to later have searching for them, what
clueless program, again, forces them to do. Do you know the famous message :  "_ORA-1403 :
No Data Found_" ? How much year of developer's or administrator's time in the world has caused
this message ? What query, what tables ?

However, what I see now, is that I forgot to copy some of these specific exceptions members
to their relative subclass of {{DatastoreException}}. I will correct this.

Never throw any core exception please. Even {{DataStoreException}} is a core exception. Of
persistence nature, but it is.
I would like it to be abstract, by the way.

> InvalidDbaseFileFormatException should extend DataStoreException
> ----------------------------------------------------------------
>
>                 Key: SIS-189
>                 URL: https://issues.apache.org/jira/browse/SIS-189
>             Project: Spatial Information Systems
>          Issue Type: Sub-task
>          Components: Shapefile
>            Reporter: Martin Desruisseaux
>            Assignee: M. Le Bihan
>              Labels: JDBC
>             Fix For: 0.7
>
>
> {{InvalidDbaseFileFormatException}} currently extends {{SQLNonTransientException}}. But
the the fact that a {{DataStore}} uses SQL or I/O operations for fetching the data is considered
internal to the data store. The higher-level exception for data stores is rather {{DataStoreException}},
which may contain a {{SQLException}}, {{IOException}} or other kind of exceptions as its cause.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message