Thread: Exception Identification - What to do with no codes?

Exception Identification - What to do with no codes?

From
Derek S
Date:
I've pored over the archives for this list, and as much documentation as
I've been able to find and I understand that the back end needs to be
updated before SQLException can be properly implemented in the JDBC
driver with failure identification codes.

I'm writing a fairly large application where certain causes of
SQLExceptions are fatal to their particular transaction, but not fatal
to the application itself.  Particularly, exceptions like duplicate key
insertion failures and such will need to be reported to the user using
friendly messages and dialog boxes.

So my question is, with all of us living in this pre-error-code age, how
are people typically building useful error messages for their users?  I
can't very well expect a user to know that the product code they've
entered is already taken from a message like "Cannot insert a duplicate
key into unique index product_unique_code".  Is there an established
practice that people use to handle this sort of thing that won't break
if the user changes the localization settings on the server and/or client?


Re: Exception Identification - What to do with no codes?

From
Daniel Serodio
Date:
I only code server-side apps, so the machine configuration is less of an
issue. Our server is configured for US locale (even thou we're in
Brazil, I think non-translated messages are more "stable"), and I parse
the Exception's message for "duplicate key", for example.

We've only upgraded the PostgreSQL backend once, and the error messages
hadn't been changed. Of course, we can only hope that the error messages
don't change between releases.

I hope someone else on the list can shed some light on the issue of
localized messages.

Hope this helps a bit,
Daniel Serodio

On Fri, 2003-02-14 at 16:59, Derek S wrote:
> I've pored over the archives for this list, and as much documentation as
> I've been able to find and I understand that the back end needs to be
> updated before SQLException can be properly implemented in the JDBC
> driver with failure identification codes.
>
> I'm writing a fairly large application where certain causes of
> SQLExceptions are fatal to their particular transaction, but not fatal
> to the application itself.  Particularly, exceptions like duplicate key
> insertion failures and such will need to be reported to the user using
> friendly messages and dialog boxes.
>
> So my question is, with all of us living in this pre-error-code age, how
> are people typically building useful error messages for their users?  I
> can't very well expect a user to know that the product code they've
> entered is already taken from a message like "Cannot insert a duplicate
> key into unique index product_unique_code".  Is there an established
> practice that people use to handle this sort of thing that won't break
> if the user changes the localization settings on the server and/or client?
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
--
Daniel Serodio <daniel@checkforte.com.br>
CheckForte


Re: Exception Identification - What to do with no codes?

From
"John Cavacas"
Date:
> So my question is, with all of us living in this pre-error-code age,
how
> are people typically building useful error messages for their users?
I
> can't very well expect a user to know that the product code they've
> entered is already taken from a message like "Cannot insert a
duplicate
> key into unique index product_unique_code".  Is there an established
> practice that people use to handle this sort of thing that won't break
> if the user changes the localization settings on the server and/or
client?

I'm currently dealing with the same issue in an application that I am
developing. The way that I'm thinking about dealing with it is really 2
fold, and to be honest I haven't actualy tried out my solution yet. I
was going to attempt it this weekend.

The way to usualy handle this is by abstracting away JDBC access and
creating various custom exception classes which have a root common
class. This way you can handle error conditions with specific type of
exceptions for each error that you are interested in catching. This
sounds like a lot of work and it is, but it does give you the freedom to
handle errors in the way you want for the application. To minimize some
of this work, you can turn to a framework.

Now, there arent many JDBC frameworks out there. But there is one that
is pretty new and is introduced in the Wrox book, Expert One-on-One J2EE
Design and Development. The author Rod Johnson has recently released the
source code into a sourceforge project. Do a search for Springframework
and checkout the CVS. The framework has much more then just the JDBC
code, and I wont bother to explain it all here, just check it out and
the book too, they are worth it.

Anyway, with this framework and the JDBC part of it, you can implement
that sort of solution. The JDBC framework has a custom
SQLExceptionTranslator interface that you can implement for custom SQL
exceptions. The author include a Oracle implementation of this class,
and since Oracle supports error codes, the solution is very clean. My
idea is to create a PostgreSQL implementation of this interface, but
since there are no error codes in PostgreSQL, I was going to parse out
strings... yep, problably not the fastest thing on the planet but I'm
going to attempt it and see how it works out.

John


Re: Exception Identification - What to do with no codes?

From
Derek S
Date:
I considered a similar solution to that, and in controlled
circumstances, it would probably work.  It has two unfortunate
consequences though:
A) if the jdbc driver changes, you're out of luck and
B) if the user has different language settings, again, out of luck.

For me, those are very significant considerations, because this is for
an office app where I won't have complete control over the environment
and localization support for at least two languages (english and french)
is a requirement.

I'm really hoping that I can find a better idea than that, because while
it is probably possible for that to work ... well it just doesn't sit
right with me.  I'd be willing and happy to contribute to the current
efforts to add error code support to the back end, but I don't really
know where to start and I'm not a terrific C programmer either way.  Are
there any other solutions out there?

regards,
Derek

John Cavacas wrote:

>Anyway, with this framework and the JDBC part of it, you can implement
>that sort of solution. The JDBC framework has a custom
>SQLExceptionTranslator interface that you can implement for custom SQL
>exceptions. The author include a Oracle implementation of this class,
>and since Oracle supports error codes, the solution is very clean. My
>idea is to create a PostgreSQL implementation of this interface, but
>since there are no error codes in PostgreSQL, I was going to parse out
>strings... yep, problably not the fastest thing on the planet but I'm
>going to attempt it and see how it works out.
>
>
>


Re: Exception Identification - What to do with no codes?

From
"John Cavacas"
Date:
> I'm really hoping that I can find a better idea than that, because
while
> it is probably possible for that to work ... well it just doesn't sit
> right with me.  I'd be willing and happy to contribute to the current
> efforts to add error code support to the back end, but I don't really
> know where to start and I'm not a terrific C programmer either way.
Are
> there any other solutions out there?

I completly agree that this solution althought it might work, it just
doesn't sit right. Of course another possibility is to use another
database. I've been looking at SAP DB which is also open source, but
seems to have a pretty steep learning curve.