Thread: Exception Identification - What to do with no codes?
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?
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
> 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
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. > > >
> 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.