On Thu, May 17, 2007 02:42, Gary Jefferson wrote: > I understand and agree that listing all possible > exceptions is not feasible, but it really would be > good practice to list the exceptions the libpqxx > itself is throwing. Otherwise, we can only resort to > "catch (...)" clauses and this is very unhelpful when > trying to debug hard problems like db load and > performance issues.
Hopefully the changes that have already been made since the 2.6.9 release will resolve some of your concerns already: http://thaiopensource.org/development/libpqxx/file/trunk/include/pqxx/except.hxx There you'll see a much richer hierarchy of libpqxx exception classes than we used to have. There is no need for "catch (...)" as far as libpqxx is concerned: all exceptions are part of the std::exception family. Also, as you can see in the link above, all libpqxx-specific exceptions are now derived from pqxx::pqxx_exception. > For example, assume that a query fails. If I don't > know which exceptions exec() might throw in this case, > I have no idea how to provide useful debug output. > Did the query fail because the connection to the db > died or was unable to be established? Did it fail > because of a lock on the table or row? Did it fail > because the record didn't exist? Did it fail because > the db was so loaded that the query/connection just > eventually timed out? Etc. I think there are two different issues here, really: one is knowing exactly which exceptions can come out of a library function, and the other is getting more information from the exception. The first can always use a bit more documentation, though I don't think it'll ever get to the point where we can say exactly what exceptions may be thrown from any function. At least not without a serious risk of getting it wrong. The second I hope is largely addressed by the expanded exception hierarchy. If you need more specific exception classes based on particular SQL error codes, just let us know (or submit a patch) and we can arrange that with the framework that is now in place. > In the meantime, any suggestions about what should I > do if I am using 2.6.8? My first choice would be: see what would be needed on top of the existing development tree (all you should really need to look at is except.hxx), post any additions that you need right here on this mailing list or file bug tickets, and insist on a speedy new release. It's about time for one, and despite array support not being finished, we may just call this one 3.0. I'd like to have everything in that new release that you need. You'll get previews along with the package maintainers and there will be a final round to get any last-minute problems fixed. The whole thing only needs to take a few days, and you can use the existing development tree as a starting point. Jeroen _______________________________________________ Libpqxx-general mailing list [email protected] http://gborg.postgresql.org/mailman/listinfo/libpqxx-general
