Обсуждение: SQLException.getErrorCode ?

 The method  SQLException.getErrorCode of the jdbc driver systematically returns 0,

 From what I have found on the web, the server doesn't have good support for error codes,
and it is the reason the jdbc driver doesn't return error codes.

The doc here talks about error codes :

 http://www.postgresql.org/docs/8.4/interactive/errcodes-appendix.html

Where are error codes support on the roadmap ?

I would like to detect things like 'table does not exist' , constraint does not exist, etc.. from the SQLException

 Is there a workaround ?

 Thanks

 And thanks for the quick replies to my previous questions ! ;-)

On Sat, 1 May 2010, Maxime L?vesque wrote:

>  The method  SQLException.getErrorCode of the jdbc driver systematically
> returns 0,
>
>  http://www.postgresql.org/docs/8.4/interactive/errcodes-appendix.html

As I said earlier you need to check SQLException.getSQLState, not
getErrorCode.  As you can see the error conditions listed in the appendix
are not all numeric so they cannot be returned via getErrorCode.

Kris Jurka

Kris Jurka <books@ejurka.com> wrote:

> As I said earlier you need to check SQLException.getSQLState, not
> getErrorCode.

Why anyone would want to use error code instead of SQLSTATE is
beyond me, but since they're out there, perhaps we should implement
getErrorCode to interpret SQLSTATE as a base 36 number, and return
that number?  It might take less time than fielding the next
complaint.  ;-)

If that sounds good, I could whip together a patch for it.

The biggest down side is that we'd have to document it....

-Kevin

On Sat, 1 May 2010, Kevin Grittner wrote:

> Kris Jurka <books@ejurka.com> wrote:
>
>> As I said earlier you need to check SQLException.getSQLState, not
>> getErrorCode.
>
> Why anyone would want to use error code instead of SQLSTATE is
> beyond me, but since they're out there, perhaps we should implement
> getErrorCode to interpret SQLSTATE as a base 36 number, and return
> that number?  It might take less time than fielding the next
> complaint.  ;-)
>
> The biggest down side is that we'd have to document it....
>

Exactly, who's going to maintain this list of alternate error code
versions?  If the main project was to put this version of the error codes
in the master table of error codes, then I guess it would be OK.  I can't
imagine proposing that though, unless there are other driver projects that
are in the same position.

Kris Jurka

 The getSQLState method is perfectly fine with me, I was mislead when I found
old posts on the web that said  that error codes were not supported at the server level.
I had first tried using the getErrorCode because all other drivers I have used
use this method. I guess making the getSQLState documentation easy available
would be the first thing to do.

 Cheers

 I was just thinking that putting the getSQLState string in the exception's toString
message would go a long way in hinting the users that postgres does provide error codes.

 Anyways thanks for all the answers ;-)

On 05/01/2010 08:17 PM, Maxime Lévesque wrote:
>
>   I was just thinking that putting the getSQLState string in the
> exception's toString
> message would go a long way in hinting the users that postgres [sic] does
> provide error codes.

Umm, the SQLException documentation is quite clear the 'getErrorCode()'
returns only vendor-specific codes and that 'getSQLState()' returns the SQL
state value.  Since the latter is standard and the former is not, that already
"goes a long way [to] hinting ... that" PG provides SQL Standard codes.
Nothing further is needed.
<http://java.sun.com/javase/6/docs/api/java/sql/SQLException.html>

It seems fair that there is a presumption of knowledge of the standard.

--
Lew