Hi,

Iīve had the same problem some time ago and I did the following:

1. First of all, I try to catch all possible exceptions BEFORE executing the query, not nulls, field types, etc., with javascript and server side checks.
2. For those errors that cannot be predicted, there is a DBMS table simply whith the primary key being the "$h->errstr" strings, and a text field is my "beatifull" message to the user.
3. All data is cached on a BerkeleyDB and tied at run time.
4. When any query is executed, it looks for the "$h->errstr" key on the Cache and, if it finds, it is substituted by that message. If it is not, I use de DB errstr.

The thing I found good in this solution is that I can have different and specific error messages for the same kind of error in different tables/fields. For example, a primaty key violation in two different tables may have different messages.

The bad thing is that these error messages become very table/project specific, non portable between event different tables/DBMS, etc. But, in my case, itīs better this way, because if my end users dont undestand the message, they pick up the phone and call me several times a day. So, the messages I write are VERY meaningfull, well explained...

Diego de Lima