[fdo-internals] RE: FDO RFC 37 - Detailed Exception is ready for review.

[Romica Dascalescu]

We could have a header file containing some Error codes, where providers can use/add new error codes, e.g.:
#define RDBI_END_OF_FETCH 0x55
A provider may choose to use error codes from that header file or use his own error codes.
In case a developer needs new (public) codes for a provider he can add them to the file without a RFC.
Optionally an application can use those codes or ignore them and process them as an int64.
However this file can get messy.

Romy.

From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Traian Stanev
Sent: Wednesday, June 17, 2009 4:38 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: FDO RFC 37 - Detailed Exception is ready for review.


Yes, like SHP. Are the error codes also going to apply to the SHP provider for example? Is it going to throw some kind of meaningful integer error code?



From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Dan Stoica
Sent: Wednesday, June 17, 2009 4:35 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: FDO RFC 37 - Detailed Exception is ready for review.

Like SHP?

Dan.

From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Traian Stanev
Sent: Wednesday, June 17, 2009 4:29 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: FDO RFC 37 - Detailed Exception is ready for review.


OK so it can be common for providers based on the FdoRdbms code, but there are a dozen other providers. What about them?

Traian


From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Dan Stoica
Sent: Wednesday, June 17, 2009 4:27 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: FDO RFC 37 - Detailed Exception is ready for review.


Ø  Do SQLServer and Oracle have the same error codes?

No, they don't. This is my point, e.g. OCIDR_RDBI_END_OF_FETCH can be mapped to RDBI_END_OF_FETCH and such type of error is common to SQLServer, MySql etc. I suppose it's not a crime to also have RDBI_ORA_xxx for specific cases (oddities).

Currently we get a localized "End of fetch" message but not the error code. And the native error message is lost along the way, although FdoException allows for a 'cause' detail...

Dan.

From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Traian Stanev
Sent: Wednesday, June 17, 2009 4:06 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: FDO RFC 37 - Detailed Exception is ready for review.


My assumption was that the integer error codes would be potentially different for each provider, since the RFC mentions native error codes for SQLServer and Oracle. Do SQLServer and Oracle have the same error codes?

Traian


From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Dan Stoica
Sent: Wednesday, June 17, 2009 3:59 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: FDO RFC 37 - Detailed Exception is ready for review.

Talking about the native error codes apparently the RFC doesn't say how they look like...

In my mind the native error codes are not necessary a direct mapping to ORA-02429, for example. A rdbms driver has limited ability to extract the exact cause anyways. (Even the native error messages are sometimes very cryptic or ambiguous or both) Therefore the numerical 'native' error code is in fact 'low level' error code and provider agnostic like RDBI_DATA_TRUNCATED.

Dan.

From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Traian Stanev
Sent: Wednesday, June 17, 2009 12:04 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: FDO RFC 37 - Detailed Exception is ready for review.


My main concern is that having native error codes encourages the client code to be non-generic, in that it would have to know which provider it is working with, in order to handle the native error code correctly. Of course, that is a concern about the client code, not FDO itself, so the client code is free to handle this any way it wants... including in bad ways.

Traian


From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Dan Stoica
Sent: Tuesday, June 16, 2009 10:10 AM
To: FDO Internals Mail List
Subject: [fdo-internals] RE: FDO RFC 37 - Detailed Exception is ready for review.

catch (FdoException* e)
{
    FdoInt64 errorCode = e->GetNativeErrorCode();
    e->Release();
    // Take some measures according to native error code
    ......
}
I think no matter how many exception subclasses are invented, the only useful thing for handling the error is the error code.

And I said before, another very useful thing to have is the ability to distinguish between errors and warnings.

Dan.

From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Leaf Li
Sent: Monday, June 15, 2009 9:37 PM
To: fdo-internals at lists.osgeo.org
Subject: [fdo-internals] FDO RFC 37 - Detailed Exception is ready for review.

All,

FDO RFC 37 - Detailed Exception is ready for review. Can you review it?
http://trac.osgeo.org/fdo/wiki/FDORfc37

Thanks,
Leaf Li
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/fdo-internals/attachments/20090617/83a23b4d/attachment-0001.html