= FDO RFC 37 - Detailed Exception =

This page contains an change request (RFC) for the FDO Open Source project.  
More FDO RFCs can be found on the [wiki:FDORfcs RFCs] page.


== Status == 
 
||RFC Template Version||(1.0)|| 
||Submission Date|| June 08, 2009 ||
||Last Modified|| Leaf Li [[Timestamp]]||
||Author||Leaf Li||
||RFC Status||draft|| 
||Implementation Status||draft||
||Proposed Milestone||3.5.0.0||
||Assigned PSC guide(s)||Greg Boone||
||'''Voting History'''|| ||
||+1|| ||
||+0|| ||
||-0|| ||
||-1|| ||
 
== Motivation ==

To handle errors more accurately by providing more detailed exception information

== Overview ==

FdoException is the root class for FDO exception handling. Currently FDO provides less than 10 exception classes derived from FdoException. So it is difficult for users to get the accurate error information so that they can take some actions according to exception type instead of just showing an error message. More exception classes will be provided in this RFC.
However, it is impossible for FDO exception classes to cover all exception type. For some FDO data sources such as Oracle and SQL Server, they already return their native error code to FDO provider when encountering errors. If FDO can return the native error code to users, users may be able to handle it properly. For exmaple,

{{{
try
{
. . . . . .
}
catch (FdoException* e)
{
FdoInt64 errorCode = e->GetNativeErrorCode();
e->Release();
// Take some measures according to native error code
. . . . . .
}
}}}

== Proposed Solution ==

The following methods will be added to class FdoException to return native error code. Providers will be updated to assign native error code when a FDO exception is created. If there is no native error code assigned, the default value is 0. 

== Managed FDO API ==

Currently FDO Managed Interfaces provide OSGeo::FDO::Common::Exception only. So we will create managed classes for all of existing exception classes and new exception classes proposed in this RFC. OSGeo::FDO::Common::Exception will be updated in a similar manner to reflect the proposed changes in this RFC too.

== Provider Implementation ==

Which providers will need to be modified to throw an accurate exception will depend on available development resources. I am fairly confident SQLite will be enhanced to support it. Adding support to SQL Server Spatial and ODBC should also be high on the priority list. Update for other providers are considered nice to have and will be implemented if resourcing and funding can be obtained.

== Test Plan ==

Existing FDO Core and Provider level unit tests will be expanded to test the proposed enhancements defined above.

== Funding/Resources ==

Autodesk to provide resources / funding.