[fdo-internals] Enhanced Exception Types in FDO

[Philipp Kast]

Hi



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.



Philipp



-----Original Message-----
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).



Greg,



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.



Best regards,

--

---------------------------------------+--------------------------------------

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

http://lists.osgeo.org/mailman/listinfo/fdo-internals
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/fdo-internals/attachments/20090603/4cf7b95e/attachment.html