FDO RFC 37 - Detailed Exception is ready for review.
|
|
| 1 2 |
Orest Halustchak
|
In reply to this post
by Trevor Wekel-3
Some javascript/style in this post has been disabled (why?)
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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Trevor Wekel 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 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 I agree with
that. Haris From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Orest
Halustchak 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Traian
Stanev 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 Like SHP? Dan. From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Traian
Stanev 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 Ø 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 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 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 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 catch
(FdoException* e)
// 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 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
|
Some javascript/style in this post has been disabled (why?)
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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Orest
Halustchak 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Trevor Wekel 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 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 I agree with
that. Haris From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Orest
Halustchak 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Traian
Stanev 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 Like SHP? Dan. From:
[hidden email] [mailto:[hidden email]]
On Behalf Of Traian Stanev 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 Ø 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 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 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 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 catch
(FdoException* e)
// 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 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 |
||||||||||||||||
Greg Boone
|
Some javascript/style in this post has been disabled (why?)
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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Dan Stoica 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Orest
Halustchak 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:
[hidden email] [mailto:[hidden email]]
On Behalf Of Trevor Wekel 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 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 I agree with
that. Haris From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Orest
Halustchak 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Traian
Stanev 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 Like SHP? Dan. From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Traian
Stanev 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 Ø 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 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 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 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 catch
(FdoException* e)
// 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 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 |
||||||||||||||||
|
Greg Boone
|
Some javascript/style in this post has been disabled (why?)
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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Greg Boone 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Dan Stoica 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:
[hidden email] [mailto:[hidden email]]
On Behalf Of Orest Halustchak 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Trevor Wekel 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 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 I agree with
that. Haris From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Orest
Halustchak 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Traian
Stanev 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 Like SHP? Dan. From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Traian
Stanev 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 Ø 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 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 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 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 catch
(FdoException* e)
// 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 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
|
Some javascript/style in this post has been disabled (why?)
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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Greg Boone 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Greg Boone 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: [hidden email]
[mailto:[hidden email]] On Behalf Of Dan Stoica 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Orest
Halustchak 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:
[hidden email] [mailto:[hidden email]]
On Behalf Of Trevor Wekel 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 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 I agree with
that. Haris From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Orest
Halustchak 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Traian
Stanev 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 Like SHP? Dan. From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Traian
Stanev 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 Ø 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 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 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 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 catch
(FdoException* e)
// 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 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
|
Some javascript/style in this post has been disabled (why?)
If you catch a fine
grained exception and if you know the provider then most likely you don’t
need the native error code. Dan. From: [hidden email]
[mailto:[hidden email]] On Behalf Of Alan Quinton 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Greg Boone 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Greg Boone 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Dan Stoica 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Orest
Halustchak 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Trevor Wekel 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 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 I agree with
that. Haris From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Orest
Halustchak 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: [hidden email]
[mailto:[hidden email]] On Behalf Of Traian
Stanev 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 Like SHP? Dan. From:
[hidden email] [mailto:[hidden email]]
On Behalf Of Traian Stanev 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 Ø 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 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 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 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 catch
(FdoException* e)
// 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 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 |
||||||||||||||||
|
Greg Boone
|
Some javascript/style in this post has been disabled (why?)
Well, our
clients have indicated that that is not the case. I defer to their previous use
cases to illustrate that point. In any case, we can never add enough fine
grained exception types to the API to cover all native error codes for all
providers. There will always be one that we miss. So, the concept as it is
specified still is valid. The client can use the exception type if available,
or the client can use the native error code as they see fit. This approach gives
them the flexibility they have requested. Greg From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Dan Stoica If you catch a
fine grained exception and if you know the provider then most likely you don’t
need the native error code. Dan. From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Alan Quinton 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Greg Boone 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Greg Boone 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: [hidden email]
[mailto:[hidden email]] On Behalf Of Dan Stoica 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Orest
Halustchak 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Trevor Wekel 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 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 I agree with
that. Haris From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Orest
Halustchak 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Traian
Stanev 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 Like SHP? Dan. From: [hidden email]
[mailto:[hidden email]] On Behalf Of Traian
Stanev 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 Ø 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 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 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 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 catch
(FdoException* e)
// 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 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 |
||||||||||||||||
| Free Embeddable Forum Powered by Nabble | Help |
