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

> 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