[fdo-internals] Enhanced Exception Types in FDO
philipp.kast at autodesk.com
Wed Jun 3 10:05:04 EDT 2009
I'm trying to provide an example where you need more information about an exception than just an exception with a text.
If you build an application on FDO that needs to handle exceptions you need information about the problem that actually caused the exception, means more than a text.
A general example: Your Application needs a column MY_NUMBER in every feature class where you store some information. When you want to write something in this column and the column does not exist, you want to add the column programmatically. But every provider is complaining with different text messages that this column does not exist.
Oracle throws ORA-00904: "MY_NUMBER": invalid identifier
SQLite throws no such column: MY_NUMBER
How are you going to handle this exception? There is no way doing it generally.
A solution would be that all FDO providers are throwing and exception ColumnDoesNotExist or a FdoException with an FDO error code, e. g. FDO-001 or whatever.
Another example with a data store specific error. You have code that wants to select data from a Oracle based feature class. If you don't have spatial index defined on this table you will get an Oracle error. E. g. ORA-13226: interface not supported without a spatial index.
So if a program wants to handle this exception it has to know what happened, getting the error code 13226. You could add the spatial index again over ISQLCommand. This is an error that can only happen on a Oracle data store, therefore it is provider specific.
This example is specific to a certain FDO provider, namely Oracle. You need to handle this specific to Oracle Provider, so you need an provider specific native error code, ORA-13226.
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Frank Warmerdam (External)
Sent: Tuesday, June 02, 2009 4:29 AM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] Enhanced Exception Types in FDO
Greg Boone wrote:
> 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).
I wonder if you could talk us through a couple examples where the current
system is inadequate. I can see value in adding some additional exception
classes to support finer grained error handling.
I'm concerned that exposing native error codes and provider id's as part
of exceptions is giving up on genericity in the FDO API. But if you can
illustrate cases where this is critical it could be ok.
From the point of view of the GDAL provider, I have no need to provide
finer grained error information from GDAL itself. GDAL has a very thin
set of native error codes, and essentially the error text (which is
formatted with potentially lots of detail) is the important cargo.
Of course, I have not done much application writing on FDO so it is hard
for me to know what things applications writers are having trouble handling.
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent
fdo-internals mailing list
fdo-internals at lists.osgeo.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fdo-internals