OSGeo.org › OSGeo Software and Data Projects › Feature Data Objects (FDO) › FDO Internals

FDO RFC 37 - Detailed Exception is ready for review.

27 messages

1 2

Leaf Li

FDO RFC 37 - Detailed Exception is ready for review.

Reply Threaded

Some javascript/style in this post has been disabled (why?)

All,

FDO RFC 37 - Detailed Exception is ready for review. Can you review it?

http://trac.osgeo.org/fdo/wiki/FDORfc37

Thanks,

Leaf Li

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

Dan Stoica

RE: FDO RFC 37 - Detailed Exception is ready for review.

Reply Threaded

Some javascript/style in this post has been disabled (why?)

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: [hidden email] [mailto:[hidden email]] On Behalf Of Leaf Li
Sent: Monday, June 15, 2009 9:37 PM
To: [hidden email]
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

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

Traian Stanev

RE: RE: FDO RFC 37 - Detailed Exception is ready for review.

Reply Threaded

Some javascript/style in this post has been disabled (why?)

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: [hidden email] [mailto:[hidden email]] 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.

All,

FDO RFC 37 - Detailed Exception is ready for review. Can you review it?

http://trac.osgeo.org/fdo/wiki/FDORfc37

Thanks,

Leaf Li

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

Dan Stoica

RE: RE: FDO RFC 37 - Detailed Exception is ready for review.

Reply Threaded

Some javascript/style in this post has been disabled (why?)

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: [hidden email] [mailto:[hidden email]] 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.

Traian

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.

All,

FDO RFC 37 - Detailed Exception is ready for review. Can you review it?

http://trac.osgeo.org/fdo/wiki/FDORfc37

Thanks,

Leaf Li

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

Traian Stanev

RE: RE: FDO RFC 37 - Detailed Exception is ready for review.

Reply Threaded

Some javascript/style in this post has been disabled (why?)

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: [hidden email] [mailto:[hidden email]] 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…

Dan.

Traian

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.

All,

FDO RFC 37 - Detailed Exception is ready for review. Can you review it?

http://trac.osgeo.org/fdo/wiki/FDORfc37

Thanks,

Leaf Li

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

Dan Stoica

RE: RE: FDO RFC 37 - Detailed Exception is ready for review.

Reply Threaded

Some javascript/style in this post has been disabled (why?)

Ø 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: [hidden email] [mailto:[hidden email]] 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.

Traian

Talking about the native error codes apparently the RFC doesn’t say how they look like…

Dan.

Traian

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.

All,

FDO RFC 37 - Detailed Exception is ready for review. Can you review it?

http://trac.osgeo.org/fdo/wiki/FDORfc37

Thanks,

Leaf Li

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

Traian Stanev

RE: RE: FDO RFC 37 - Detailed Exception is ready for review.

Reply Threaded

Some javascript/style in this post has been disabled (why?)

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: [hidden email] [mailto:[hidden email]] 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?

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.

Traian

Talking about the native error codes apparently the RFC doesn’t say how they look like…

Dan.

Traian

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.

All,

FDO RFC 37 - Detailed Exception is ready for review. Can you review it?

http://trac.osgeo.org/fdo/wiki/FDORfc37

Thanks,

Leaf Li

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

Dan Stoica

RE: RE: FDO RFC 37 - Detailed Exception is ready for review.

Reply Threaded

Some javascript/style in this post has been disabled (why?)

Like SHP?

Dan.

From: [hidden email] [mailto:[hidden email]] 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

Ø Do SQLServer and Oracle have the same error codes?

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.

Traian

Talking about the native error codes apparently the RFC doesn’t say how they look like…

Dan.

Traian

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.

All,

FDO RFC 37 - Detailed Exception is ready for review. Can you review it?

http://trac.osgeo.org/fdo/wiki/FDORfc37

Thanks,

Leaf Li

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

Traian Stanev

RE: RE: FDO RFC 37 - Detailed Exception is ready for review.

Reply Threaded

Some javascript/style in this post has been disabled (why?)

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: [hidden email] [mailto:[hidden email]] 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.

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

Traian

Ø Do SQLServer and Oracle have the same error codes?

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.

Traian

Talking about the native error codes apparently the RFC doesn’t say how they look like…

Dan.

Traian

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.

All,

FDO RFC 37 - Detailed Exception is ready for review. Can you review it?

http://trac.osgeo.org/fdo/wiki/FDORfc37

Thanks,

Leaf Li

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

Dan Stoica

RE: RE: FDO RFC 37 - Detailed Exception is ready for review.

Reply Threaded

Some javascript/style in this post has been disabled (why?)

No. There is nothing ‘native’ (i.e. an underlying engine of some sort that the provider talks to) in this case.

From: [hidden email] [mailto:[hidden email]] 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?

Like SHP?

Dan.

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

Traian

Ø Do SQLServer and Oracle have the same error codes?

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.

Traian

Talking about the native error codes apparently the RFC doesn’t say how they look like…

Dan.

Traian

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.

All,

FDO RFC 37 - Detailed Exception is ready for review. Can you review it?

http://trac.osgeo.org/fdo/wiki/FDORfc37

Thanks,

Leaf Li

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

Orest Halustchak

RE: RE: FDO RFC 37 - Detailed Exception is ready for review.

Reply Threaded

In reply to this post by Traian Stanev

Some javascript/style in this post has been disabled (why?)

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.

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?

Like SHP?

Dan.

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

Traian

Ø Do SQLServer and Oracle have the same error codes?

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.

Traian

Talking about the native error codes apparently the RFC doesn’t say how they look like…

Dan.

Traian

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.

All,

FDO RFC 37 - Detailed Exception is ready for review. Can you review it?

http://trac.osgeo.org/fdo/wiki/FDORfc37

Thanks,

Leaf Li

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

Romica Dascalescu

RE: RE: FDO RFC 37 - Detailed Exception is ready for review.

Reply Threaded

In reply to this post by Traian Stanev

Some javascript/style in this post has been disabled (why?)

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.

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?

Like SHP?

Dan.

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

Traian

Ø Do SQLServer and Oracle have the same error codes?

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.

Traian

Talking about the native error codes apparently the RFC doesn’t say how they look like…

Dan.

Traian

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.

All,

FDO RFC 37 - Detailed Exception is ready for review. Can you review it?

http://trac.osgeo.org/fdo/wiki/FDORfc37

Thanks,

Leaf Li

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

Traian Stanev

RE: RE: FDO RFC 37 - Detailed Exception is ready for review.

Reply Threaded

Some javascript/style in this post has been disabled (why?)

Yeah such a file would get messy, especially if the error codes for different errors of different providers had the same numeric value and people had to remap them to different numbers.

I share the sentiment with what Orest said just now, that it’s ok to return the raw native error code, but the client code has to be reasonable about how it uses the information.

Traian

From: [hidden email] [mailto:[hidden email]] On Behalf Of Romica Dascalescu
Sent: Wednesday, June 17, 2009 4:46 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: FDO RFC 37 - Detailed Exception is ready for review.

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.

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?

Like SHP?

Dan.

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

Traian

Ø Do SQLServer and Oracle have the same error codes?

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.

Traian

Talking about the native error codes apparently the RFC doesn’t say how they look like…

Dan.

Traian

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.

All,

FDO RFC 37 - Detailed Exception is ready for review. Can you review it?

http://trac.osgeo.org/fdo/wiki/FDORfc37

Thanks,

Leaf Li

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

Alan Quinton

RE: RE: FDO RFC 37 - Detailed Exception is ready for review.

Reply Threaded

In reply to this post by Dan Stoica

Some javascript/style in this post has been disabled (why?)

Why is it OK for APIs like JDBC and ODBC to expose a data source specific error codes and not FDO? Probably because it’s certainly useful in some scenarios, and to me that trumps arguments about encouraging bad data source specific coding behavior…

Alan

From: [hidden email] [mailto:[hidden email]] On Behalf Of Dan Stoica
Sent: Wednesday, June 17, 2009 1:44 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: FDO RFC 37 - Detailed Exception is ready for review.

No. There is nothing ‘native’ (i.e. an underlying engine of some sort that the provider talks to) in this case.

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?

Like SHP?

Dan.

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

Traian

Ø Do SQLServer and Oracle have the same error codes?

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.

Traian

Talking about the native error codes apparently the RFC doesn’t say how they look like…

Dan.

Traian

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.

All,

FDO RFC 37 - Detailed Exception is ready for review. Can you review it?

http://trac.osgeo.org/fdo/wiki/FDORfc37

Thanks,

Leaf Li

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

Haris Kurtagic

RE: RE: FDO RFC 37 - Detailed Exception is readyfor review.

Reply Threaded

In reply to this post by Orest Halustchak

Some javascript/style in this post has been disabled (why?)

I agree with that.

Haris

From: [hidden email] [mailto:[hidden email]] 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.

Thanks,

Orest.

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?

Like SHP?

Dan.

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

Traian

Ø Do SQLServer and Oracle have the same error codes?

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.

Traian

Talking about the native error codes apparently the RFC doesn’t say how they look like…

Dan.

Traian

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.

All,

FDO RFC 37 - Detailed Exception is ready for review. Can you review it?

http://trac.osgeo.org/fdo/wiki/FDORfc37

Thanks,

Leaf Li

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

Dan Stoica

RE: RE: FDO RFC 37 - Detailed Exception is readyfor review.

Reply Threaded

Some javascript/style in this post has been disabled (why?)

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: [hidden email] [mailto:[hidden email]] 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

Thanks,

Orest.

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?

Like SHP?

Dan.

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

Traian

Ø Do SQLServer and Oracle have the same error codes?

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.

Traian

Talking about the native error codes apparently the RFC doesn’t say how they look like…

Dan.

Traian

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.

All,

FDO RFC 37 - Detailed Exception is ready for review. Can you review it?

http://trac.osgeo.org/fdo/wiki/FDORfc37

Thanks,

Leaf Li

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

Trevor Wekel-3

RE: RE: FDO RFC 37 - Detailed Exception is readyfor review.

Reply Threaded

Some javascript/style in this post has been disabled (why?)

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: [hidden email] [mailto:[hidden email]] 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.

I agree with that.

Haris

Thanks,

Orest.

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?

Like SHP?

Dan.

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

Traian

Ø Do SQLServer and Oracle have the same error codes?

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.

Traian

Talking about the native error codes apparently the RFC doesn’t say how they look like…

Dan.

Traian

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.

All,

FDO RFC 37 - Detailed Exception is ready for review. Can you review it?

http://trac.osgeo.org/fdo/wiki/FDORfc37

Thanks,

Leaf Li

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

Dan Stoica

RE: RE: FDO RFC 37 - Detailed Exception is readyfor review.

Reply Threaded

Some javascript/style in this post has been disabled (why?)

Sounds good, but still: I assume the client needs to know also it’s a ORA error in order to take a specific action.

Dan.

From: [hidden email] [mailto:[hidden email]] 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.

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

Trevor

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.

I agree with that.

Haris

Thanks,

Orest.

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?

Like SHP?

Dan.

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

Traian

Ø Do SQLServer and Oracle have the same error codes?

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.

Traian

Talking about the native error codes apparently the RFC doesn’t say how they look like…

Dan.

Traian

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.

All,

FDO RFC 37 - Detailed Exception is ready for review. Can you review it?

http://trac.osgeo.org/fdo/wiki/FDORfc37

Thanks,

Leaf Li

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

Haris Kurtagic

RE: RE: FDO RFC 37 - Detailed Exception is readyforreview.

Reply Threaded

In reply to this post by Dan Stoica

Some javascript/style in this post has been disabled (why?)

present "native" error message.

Regarding RFC, is it going to be GetNativeErrorText function or it is supposed to be part of Fdo exception already ?

Haris

From: [hidden email] [mailto:[hidden email]] On Behalf Of Dan Stoica
Sent: Wednesday, June 17, 2009 11:00 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: FDO RFC 37 - Detailed Exception is readyforreview.

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.

I agree with that.

Haris

Thanks,

Orest.

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?

Like SHP?

Dan.

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

Traian

Ø Do SQLServer and Oracle have the same error codes?

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.

Traian

Talking about the native error codes apparently the RFC doesn’t say how they look like…

Dan.

Traian

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.

All,

FDO RFC 37 - Detailed Exception is ready for review. Can you review it?

http://trac.osgeo.org/fdo/wiki/FDORfc37

Thanks,

Leaf Li

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

Orest Halustchak

RE: RE: FDO RFC 37 - Detailed Exception is readyforreview.

Reply Threaded

Some javascript/style in this post has been disabled (why?)

I would assume that the existing FdoException message would serve this purpose.

Orest.

From: [hidden email] [mailto:[hidden email]] On Behalf Of Haris Kurtagic
Sent: Wednesday, June 17, 2009 5:52 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: FDO RFC 37 - Detailed Exception is readyforreview.

present "native" error message.

Regarding RFC, is it going to be GetNativeErrorText function or it is supposed to be part of Fdo exception already ?

Haris

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.

I agree with that.

Haris

Thanks,

Orest.

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?

Like SHP?

Dan.

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

Traian

Ø Do SQLServer and Oracle have the same error codes?

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.

Traian

Talking about the native error codes apparently the RFC doesn’t say how they look like…

Dan.

Traian

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.

All,

FDO RFC 37 - Detailed Exception is ready for review. Can you review it?

http://trac.osgeo.org/fdo/wiki/FDORfc37

Thanks,

Leaf Li

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

1 2