Enhanced Exception Types in FDO
|
|
Some javascript/style in this post has been disabled (why?)
Hi All, I am currently struggling with the topic of error handling and
exceptions in FDO, FDO Providers and applications that use them. I would like
to get some feedback from the community on how we could possibly resolve this
issue in the next planned release of FDO (trunk). Currently, the FDO API uses a throw/catch exception handling solution with the FdoException class being the root class for all exception types in the FDO architecture. The FDO API currently has less than 10 derived exception classes to indicate the specific type of exception that has occurred in a provider, or application. The type of the exception object along with the exception message attached to the exception is the general extent of the error information that application developers can use to write provider/application specific error handling code. This lack of information makes it difficult for clients to get enough information concerning the error that occurred to take an appropriate action. Because of this limitation, applications are generally forced to catch only the base FdoException type, exit the routine gracefully, and show the error message to the user. Typically this mechanism really breaks down when dealing with database solutions such as Oracle, ODBC, MySQL, SQLite, etc.. where the underlying implementation provides a native error code to represent an error that has occurred. This native error code sometimes is accompanied by an error string or can be interpreted by the provider to generate an error message. However, for the client catching the error from the provider, interpreting the string is a difficult task. The client typically does not want to parse the string and generally has no knowledge of the native error that has occurred. So, how can we improve this mechanism and still allow developers
to write generic applications against FDO that work with many types of
providers? One idea has been to extend the number of generic exception
class types that FDO supports to support generic exceptions such as… Constraint Exception: NullPropertyValue OutOfRangePropertyValue NotUniquePropertyvalue NotInListPropertyValue Schema Exceptions: SchemaDoesNotExist SchemaAlreadyExists ClassDoesNotExist ClassAlreadyExists PropertyDoesNotExist PropertyAlreadyExists Connection Exceptions: NotConnected WrongConnectionParameterValue InsufficientPrivaledges Command Exceptions: SQLCommand InvalidSQLStatement
While this approach would allow a certain level of
flexibility in writing standardized FDO applications and its utilities, it still
does not offer any real ability to access the underlying native error code in a
generic manner, especially for RDBMS providers. Here are some other quick ideas that I thought of: 1)
Add RDBMS specific exception types to the FDO API 2)
Add a GetNativeErrorCode method to FdoException that
would return the error code returned by the underlying datastore/database The first idea of adding RDBMS specific exception types may
help a little, but may further complicate the try.. catch error handling strategy
that applications are forced to implement. It also may limit the manner in
which generic code can be written, and in the end still not be sufficient to
meet all our clients requirements. The GetNativeErrorCode thought is a good one, but by using
it in an application, they would really have to know which provider returned
that code and do some form of look-up to determine what it actually means. This
would reduce the amount of generic provider agnostic code that applications can
effectively write. I can see IsOracle() or IsPostGIS() calls creeping into applications
and developers attempt to take advantage. So, with these thoughts in mind, I would like to solicit feedback
from the community to gather your thoughts and ideas on how this issue could be
dealt with effectively. There has been a lot of provider development on
Oracle/PostGIS/SQLite/MySQL/ODBC, etc, in the last number of years. What do you
as provider developers think of the ideas expressed above? What error handling
issues have you run up against that would have liked to have seen solved
generically in the FDO API? What ideas and thoughts do you have that may
help me come to some conclusions on this topic and move forward? Regards, Greg _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||
image002.emz (18K)
|
|
||||||||
|
In reply to this post
by Greg Boone
|
||||||||
|
|
||||||||
|
In reply to this post
by Frank Warmerdam
|
||||||||
|
In reply to this post
by Greg Boone
Some javascript/style in this post has been disabled (why?)
Hi, Some comments: Ø One
idea has been to extend the number of generic exception I think deriving from a derived
exception just adds complexity without real benefit. That is, it would be redundant
since they differ only by the error message. I don’t see an application
doing a catch() for each exception type or doing dynamic cast for handling it. A
better (and cheaper) alternative is to add a numeric FDO error code. Ø The
GetNativeErrorCode thought is a good one, but by using it in an application,
they would really have to know which provider returned that code Usually a native error message contains
some sort of RDBMS auto identification. The code that retrieves the native
error can add a prefix in case it doesn’t. Ø and
do some form of look-up to determine what it actually means. The underlying code can figure out
what it means because we know the specific RDBMS operation that just generated
it (see the RDBI error codes). A more detailed explanation is provided by the
native error code. A different issue: I believe it would
be useful to be able to distinguish between fatal errors and warnings. One little
flag will do it. Alternatively, the numeric code for warnings should be (say) over
10000 and add a method IsAWarning() to hide the details. From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Greg Boone Hi All, I am currently struggling with the topic of error handling
and exceptions in FDO, FDO Providers and applications that use them. I would
like to get some feedback from the community on how we could possibly resolve
this issue in the next planned release of FDO (trunk). Currently, the FDO API uses a throw/catch exception handling solution with the FdoException class being the root class for all exception types in the FDO architecture. The FDO API currently has less than 10 derived exception classes to indicate the specific type of exception that has occurred in a provider, or application. The type of the exception object along with the exception message attached to the exception is the general extent of the error information that application developers can use to write provider/application specific error handling code. This lack of information makes it difficult for clients to get enough information concerning the error that occurred to take an appropriate action. Because of this limitation, applications are generally forced to catch only the base FdoException type, exit the routine gracefully, and show the error message to the user. Typically this mechanism really breaks down when dealing with database solutions such as Oracle, ODBC, MySQL, SQLite, etc.. where the underlying implementation provides a native error code to represent an error that has occurred. This native error code sometimes is accompanied by an error string or can be interpreted by the provider to generate an error message. However, for the client catching the error from the provider, interpreting the string is a difficult task. The client typically does not want to parse the string and generally has no knowledge of the native error that has occurred. So, how can we improve this mechanism and still allow
developers to write generic applications against FDO that work with many types
of providers? One idea has been to extend the number of generic exception
class types that FDO supports to support generic exceptions such as… Constraint Exception: NullPropertyValue OutOfRangePropertyValue NotUniquePropertyvalue NotInListPropertyValue Schema Exceptions: SchemaDoesNotExist SchemaAlreadyExists ClassDoesNotExist ClassAlreadyExists PropertyDoesNotExist PropertyAlreadyExists Connection Exceptions: NotConnected WrongConnectionParameterValue InsufficientPrivaledges Command Exceptions: SQLCommand InvalidSQLStatement
While this approach would allow a certain level of
flexibility in writing standardized FDO applications and its utilities, it
still does not offer any real ability to access the underlying native error
code in a generic manner, especially for RDBMS providers. Here are some other quick ideas that I thought of: 1)
Add RDBMS specific exception types to the FDO API 2)
Add a GetNativeErrorCode method to FdoException that
would return the error code returned by the underlying datastore/database The first idea of adding RDBMS specific exception types may
help a little, but may further complicate the try.. catch error handling
strategy that applications are forced to implement. It also may limit the
manner in which generic code can be written, and in the end still not be sufficient
to meet all our clients requirements. The GetNativeErrorCode thought
is a good one, but by using it in an application, they would really have to
know which provider returned that code and do some form of look-up to determine
what it actually means. This would reduce the amount of generic provider
agnostic code that applications can effectively write. I can see IsOracle() or
IsPostGIS() calls creeping into applications and developers attempt to take
advantage. So, with these thoughts in mind, I would like to solicit
feedback from the community to gather your thoughts and ideas on how this issue
could be dealt with effectively. There has been a lot of provider development
on Oracle/PostGIS/SQLite/MySQL/ODBC, etc, in the last number of years. What do
you as provider developers think of the ideas expressed above? What error
handling issues have you run up against that would have liked to have seen
solved generically in the FDO API? What ideas and thoughts do you have
that may help me come to some conclusions on this topic and move forward? Regards, Greg _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||
|
|
Some javascript/style in this post has been disabled (why?)
[GB] See inline… From:
[hidden email] [mailto:[hidden email]]
On Behalf Of Dan Stoica Hi, Some comments: Ø One
idea has been to extend the number of generic exception I think deriving from a derived
exception just adds complexity without real benefit. That is, it would be
redundant since they differ only by the error message. I don’t see
an application doing a catch() for each exception type or doing dynamic cast
for handling it. A better (and cheaper) alternative is to add a numeric FDO
error code. [GB] I don’t see it as
being redundant. The fact that the exception classes are typed allows for
greater flexibility when adding exception handling code. Applications would not
catch every exception separately in all cases. Only if there is an expectation
that one of the new exceptions will be thrown will the application insert the
specific exception handling code, catch the error and take subsequent action. All
other errors can be caught by a application level error handling mechanism. However, I do agree that the
extended exception types alone may not be sufficient for the application to
take a secondary action. I guess I see these new types being used in conjunction
with other extensions to the exception system in FDO to provide greater
flexibility to the user. Ø The
GetNativeErrorCode thought is a good one, but by using it in an application,
they would really have to know which provider returned that code Usually a native error message
contains some sort of RDBMS auto identification. The code that retrieves the
native error can add a prefix in case it doesn’t. [GB] Even if a prefix is
added, the client application would require some code to determine what the
prefix is. For me, this is not that much different than having specialized code
to determine what provider was being accessed when the exception was thrown. 6
of one half a dozen of another…. NOTE: I must point out here
that while messy, the concept of native error code handling is an issue that other
"data format agnostic" APIs have to deal with and do so without great
gnashing of teeth. This includes ADO.Net and JDBC. So, this idea is not without
precedent. We simply may have to bite the proverbial bullet here and accept
some form of native error code concept in the API if we wish greater adoption. Ultimately,
it will be up to the clients themselves to determine if they wish to handle
these codes, and in turn write less provider-agnostic implementations. Ø and
do some form of look-up to determine what it actually means. The underlying code can figure
out what it means because we know the specific RDBMS operation that just
generated it (see the RDBI error codes). A more detailed explanation is
provided by the native error code. A different issue: I believe it
would be useful to be able to distinguish between fatal errors and warnings.
One little flag will do it. Alternatively, the numeric code for warnings should
be (say) over 10000 and add a method IsAWarning() to hide the details. From:
[hidden email] [mailto:[hidden email]]
On Behalf Of Greg Boone Hi All, I am currently struggling with the topic of error handling and
exceptions in FDO, FDO Providers and applications that use them. I would like
to get some feedback from the community on how we could possibly resolve this
issue in the next planned release of FDO (trunk). Currently, the FDO API uses a throw/catch exception handling solution with the FdoException class being the root class for all exception types in the FDO architecture. The FDO API currently has less than 10 derived exception classes to indicate the specific type of exception that has occurred in a provider, or application. The type of the exception object along with the exception message attached to the exception is the general extent of the error information that application developers can use to write provider/application specific error handling code. This lack of information makes it difficult for clients to get enough information concerning the error that occurred to take an appropriate action. Because of this limitation, applications are generally forced to catch only the base FdoException type, exit the routine gracefully, and show the error message to the user. Typically this mechanism really breaks down when dealing with database solutions such as Oracle, ODBC, MySQL, SQLite, etc.. where the underlying implementation provides a native error code to represent an error that has occurred. This native error code sometimes is accompanied by an error string or can be interpreted by the provider to generate an error message. However, for the client catching the error from the provider, interpreting the string is a difficult task. The client typically does not want to parse the string and generally has no knowledge of the native error that has occurred. So, how can we improve this mechanism and still allow
developers to write generic applications against FDO that work with many types
of providers? One idea has been to extend the number of generic exception
class types that FDO supports to support generic exceptions such as… Constraint Exception: NullPropertyValue OutOfRangePropertyValue NotUniquePropertyvalue NotInListPropertyValue Schema Exceptions: SchemaDoesNotExist SchemaAlreadyExists ClassDoesNotExist ClassAlreadyExists PropertyDoesNotExist PropertyAlreadyExists Connection Exceptions: NotConnected WrongConnectionParameterValue InsufficientPrivaledges Command Exceptions: SQLCommand InvalidSQLStatement
While this approach would allow a certain level of
flexibility in writing standardized FDO applications and its utilities, it
still does not offer any real ability to access the underlying native error
code in a generic manner, especially for RDBMS providers. Here are some other quick ideas that I thought of: 1)
Add RDBMS specific exception types to the FDO API 2)
Add a GetNativeErrorCode method to FdoException that
would return the error code returned by the underlying datastore/database The first idea of adding RDBMS specific exception types may
help a little, but may further complicate the try.. catch error handling
strategy that applications are forced to implement. It also may limit the
manner in which generic code can be written, and in the end still not be
sufficient to meet all our clients requirements. The GetNativeErrorCode thought
is a good one, but by using it in an application, they would really have to
know which provider returned that code and do some form of look-up to determine
what it actually means. This would reduce the amount of generic provider
agnostic code that applications can effectively write. I can see IsOracle() or
IsPostGIS() calls creeping into applications and developers attempt to take
advantage. So, with these thoughts in mind, I would like to solicit
feedback from the community to gather your thoughts and ideas on how this issue
could be dealt with effectively. There has been a lot of provider development
on Oracle/PostGIS/SQLite/MySQL/ODBC, etc, in the last number of years. What do
you as provider developers think of the ideas expressed above? What error
handling issues have you run up against that would have liked to have seen
solved generically in the FDO API? What ideas and thoughts do you have
that may help me come to some conclusions on this topic and move forward? Regards, Greg _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||
|
|
Some javascript/style in this post has been disabled (why?)
Let’s have a look at JDBC
and error handling: http://www.docjar.com/docs/api/java/sql/SQLException.html Basically there are a bunch of
derived classes (of little interest of us), but the most important are SQLWarningException
and DataTruncationException. I think this SQLException class is
pretty powerful and flexible. Note the error messages can be chained. Here are its
members: 1.
A string describing the error. This is used as the Java Exception
message, available via the getMessage method. 2.
A "SQLState" string, which follows the XOPEN SQLState
conventions. 3.
An integer error code that is specific to each vendor. We could easily do something
similar by extending FdoIException API. A chain of messages limited to 2 items
is equivalent to GetNativeErrorCode() approach. (as opposed to creating N
subclasses and keep adding new ones in the future). Hope this clarifies my position. From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Greg Boone [GB] See inline… From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Dan Stoica Hi, Some comments: Ø One
idea has been to extend the number of generic exception I think deriving from a derived
exception just adds complexity without real benefit. That is, it would be
redundant since they differ only by the error message. I don’t see
an application doing a catch() for each exception type or doing dynamic cast
for handling it. A better (and cheaper) alternative is to add a numeric FDO
error code. [GB] I don’t see it as
being redundant. The fact that the exception classes are typed allows for
greater flexibility when adding exception handling code. Applications would not
catch every exception separately in all cases. Only if there is an expectation
that one of the new exceptions will be thrown will the application insert the
specific exception handling code, catch the error and take subsequent action.
All other errors can be caught by a application level error handling mechanism. However, I do agree that the
extended exception types alone may not be sufficient for the application to
take a secondary action. I guess I see these new types being used in
conjunction with other extensions to the exception system in FDO to provide
greater flexibility to the user. Ø The
GetNativeErrorCode thought is a good one, but by using it in an application,
they would really have to know which provider returned that code Usually a native error message
contains some sort of RDBMS auto identification. The code that retrieves the
native error can add a prefix in case it doesn’t. [GB] Even if a prefix is
added, the client application would require some code to determine what the
prefix is. For me, this is not that much different than having specialized code
to determine what provider was being accessed when the exception was thrown.
6 of one half a dozen of another…. NOTE: I must point out here
that while messy, the concept of native error code handling is an issue that
other "data format agnostic" APIs have to deal with and do so
without great gnashing of teeth. This includes ADO.Net and JDBC. So, this idea
is not without precedent. We simply may have to bite the proverbial bullet here
and accept some form of native error code concept in the API if we wish greater
adoption. Ultimately, it will be up to the clients themselves to determine if
they wish to handle these codes, and in turn write less provider-agnostic
implementations. Ø and
do some form of look-up to determine what it actually means. The underlying code can figure
out what it means because we know the specific RDBMS operation that just generated
it (see the RDBI error codes). A more detailed explanation is provided by the
native error code. A different issue: I believe it
would be useful to be able to distinguish between fatal errors and warnings. One
little flag will do it. Alternatively, the numeric code for warnings should be
(say) over 10000 and add a method IsAWarning() to hide the details. From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Greg Boone Hi All, I am currently struggling with the topic of error handling
and exceptions in FDO, FDO Providers and applications that use them. I would
like to get some feedback from the community on how we could possibly resolve
this issue in the next planned release of FDO (trunk). Currently, the FDO API uses a throw/catch exception handling solution with the FdoException class being the root class for all exception types in the FDO architecture. The FDO API currently has less than 10 derived exception classes to indicate the specific type of exception that has occurred in a provider, or application. The type of the exception object along with the exception message attached to the exception is the general extent of the error information that application developers can use to write provider/application specific error handling code. This lack of information makes it difficult for clients to get enough information concerning the error that occurred to take an appropriate action. Because of this limitation, applications are generally forced to catch only the base FdoException type, exit the routine gracefully, and show the error message to the user. Typically this mechanism really breaks down when dealing with database solutions such as Oracle, ODBC, MySQL, SQLite, etc.. where the underlying implementation provides a native error code to represent an error that has occurred. This native error code sometimes is accompanied by an error string or can be interpreted by the provider to generate an error message. However, for the client catching the error from the provider, interpreting the string is a difficult task. The client typically does not want to parse the string and generally has no knowledge of the native error that has occurred. So, how can we improve this mechanism and still allow
developers to write generic applications against FDO that work with many types
of providers? One idea has been to extend the number of generic exception
class types that FDO supports to support generic exceptions such as… Constraint Exception: NullPropertyValue OutOfRangePropertyValue NotUniquePropertyvalue NotInListPropertyValue Schema Exceptions: SchemaDoesNotExist SchemaAlreadyExists ClassDoesNotExist ClassAlreadyExists PropertyDoesNotExist PropertyAlreadyExists Connection Exceptions: NotConnected WrongConnectionParameterValue InsufficientPrivaledges Command Exceptions: SQLCommand InvalidSQLStatement
While this approach would allow a certain level of
flexibility in writing standardized FDO applications and its utilities, it
still does not offer any real ability to access the underlying native error
code in a generic manner, especially for RDBMS providers. Here are some other quick ideas that I thought of: 1)
Add RDBMS specific exception types to the FDO API 2)
Add a GetNativeErrorCode method to FdoException that
would return the error code returned by the underlying datastore/database The first idea of adding RDBMS specific exception types may
help a little, but may further complicate the try.. catch error handling
strategy that applications are forced to implement. It also may limit the
manner in which generic code can be written, and in the end still not be
sufficient to meet all our clients requirements. The GetNativeErrorCode thought
is a good one, but by using it in an application, they would really have to know
which provider returned that code and do some form of look-up to determine what
it actually means. This would reduce the amount of generic provider agnostic
code that applications can effectively write. I can see IsOracle() or
IsPostGIS() calls creeping into applications and developers attempt to take
advantage. So, with these thoughts in mind, I would like to solicit
feedback from the community to gather your thoughts and ideas on how this issue
could be dealt with effectively. There has been a lot of provider development
on Oracle/PostGIS/SQLite/MySQL/ODBC, etc, in the last number of years. What do
you as provider developers think of the ideas expressed above? What error
handling issues have you run up against that would have liked to have seen solved
generically in the FDO API? What ideas and thoughts do you have that may
help me come to some conclusions on this topic and move forward? Regards, Greg _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||
| Free Embeddable Forum Powered by Nabble | Help |
