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

Thu Jun 18 11:20:29 EDT 2009

I'll second that. If you want to handle FDO errors that are provider agnostic then handle FdoException or some of the new derived types which are being proposed here. Otherwise, if you know the provider and want to handle the native code you can do that as well.

Alan

From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Greg Boone
Sent: Thursday, June 18, 2009 8:11 AM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: FDO RFC 37 - Detailed Exception is readyfor review.

Sorry....

The reason I am not in favor of having this native code mapped to a common FDO code is that would a) require clients to jump through hoops to compile and link, b) water down the original concept of returning the native code in the first place.

From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Greg Boone
Sent: Thursday, June 18, 2009 11:05 AM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: FDO RFC 37 - Detailed Exception is readyfor review.

As I see it, the purpose of the additional method is to simply return the native error code thrown by the underlying data store implementation. The purpose is not map it to a common FDO error code. The reason I am in favor of having this native code mapped to a common FDO code is that would a) require clients to jump through hoops to compile and link, b) water down the original concept of returning the native code in the first place.

What the client does with the error code is up to the client.

Greg

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

The question is: what is the caller going to do with this 'native error code'?
If the purpose is to get a 'native error message' then the answer is simple: he doesn't need it since this message is already available via GetCause() and GetRootCause().

Note: FdoException allows chaining the exceptions. Which means the error code we need is the deepest error code or...?

Therefore GetNativeErrorCode()is not a proper name. It should be GetErrorCode() instead and it should return FDO error codes as I suggested before. I guess the application has to navigate down the chain and extract the error code(s).

Dan.

From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Orest Halustchak
Sent: Thursday, June 18, 2009 9:07 AM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: FDO RFC 37 - Detailed Exception is readyfor review.

I think this is one of those things that are good in theory but in practice are hard to make work and keep up to date with all the providers. Think also of the non-open source commercial providers too and how this would fit. How does the agnostic list of codes get kept up to date?

Thanks,
Orest.

From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Trevor Wekel
Sent: Wednesday, June 17, 2009 5:25 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: FDO RFC 37 - Detailed Exception is readyfor review.

Could we add a method "int GetAgnosticCode(int nativeCode)" to each Fdo provider which would return a provider agnostic error code, if one exists, for the native error code?  The implementation would basically be an error code lookup table coded specifically for each provider.

External applications could then call GetAgnosticCode and do something based on the results.

Trevor

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:00 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: FDO RFC 37 - Detailed Exception is readyfor review.

I can have an error code = 714 for 3 different providers but meaning something different in each case.
How is a provider agnostic client supposed to interpret this number?

Dan.

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

I agree with that.
Haris

From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Orest Halustchak
Sent: Wednesday, June 17, 2009 10:45 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: FDO RFC 37 - Detailed Exception is readyfor review.

I think if we advertise "native" error code, then it should just be the code returned by the underlying server. Yes, that will be different for different providers. I'm also concerned about client applications writing a lot of provider specific code, but I do understand that there will be cases where applications will want this information and we should just pass it through. As someone mentioned in a related thread, this is consistent with other data access API's out there.

Thanks,
Orest.

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/20090618/f6511f37/attachment-0001.html