Jeroen,
Thanks for the very informative reply, even though I
mis-sent the original message. In order to get the
whole thread in the list, I'm going to top reply
(please forgive):
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.
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.
Perhaps the problem is not that the libpqxx exceptions
aren't documented well, but that they are being used
at all in the first place when a return code would
have served better? Or maybe there is a better way to
debug problems like these that I'm just completely
missing? Maybe the solution is 2.6.10, and catch
clauses just for the [I assume] fewer base exception
types?
In the meantime, any suggestions about what should I
do if I am using 2.6.8?
Thanks,
Gary
--- "Jeroen T. Vermeulen" <[EMAIL PROTECTED]> wrote:
> On Wed, May 16, 2007 23:32, Gary Jefferson wrote:
> >> The problem I'm facing is that pqxx has four
> >> different top-level exception classes
> >> (broken_connection, sql_error, in_double_error,
> >> and internal_error)
>
> Hello Gary,
>
> I'm not sure why you sent this to me instead of to
> the mailing list. The
> problem mentioned above was resolved some time ago,
> though after the
> release of 2.6.9. I guess it's time for a 2.6.10!
>
>
> > Are those really the only exceptions we need to
> look
> > out for? One of the deficiencies of the pqxx docs
> > that I'm running into (or maybe one of my
> deficiencies
> > in trying to find the info) is that it isn't clear
> > what methods can throw what exceptions, nor what
> all
> > the exceptions are...
>
> Documenting that would do more damage than good. It
> is just about
> impossible to keep track of these things except in a
> few isolated cases.
> You'll see that some declarations in libpqxx do
> guarantee that no
> exceptions are thrown at all, but any nontrivial
> piece of code in C++ can
> generate many different exception types. You'd end
> up saying either "this
> throws std::exception or subclasses" (which boils
> down to the same thing
> as not specifying at all) or lying.
>
>
> > Maybe I'm just revealing my noobishness, but for
> > example, what are the exceptions that exec() can
> > throw?
>
> Many, and some of those can come from the C++
> standard library, for
> example. Consider this code:
>
> string output = "Computing percentage.\n";
> p = x/(100*y[n]);
> cout << output + "The result is: " << p << '%' <<
> endl;
>
> This could throw a number of exceptions: you could
> run out of memory at
> several points, you could be dividing by zero,
> writing to cout could fail,
> the array indexing could be out of bounds, or there
> could be some wildly
> unexpected exception while executing the []
> operator. If this code is in
> a template, and the type of y depends on a template
> parameter, you'll have
> to wait until template instantiation before you can
> even research the
> possible set of exception types.
>
> So in general, except in a very few sensitive
> places, don't even try to
> know exactly what exceptions could be thrown! I
> know it's hard when you
> try to handle various kinds of errors well, but it's
> just a bottomless
> pit.
>
>
> Jeroen
>
>
>
____________________________________________________________________________________Give
spam the boot. Take control with tough spam protection in the all-new Yahoo!
Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/newmail_html.html
_______________________________________________
Libpqxx-general mailing list
[email protected]
http://gborg.postgresql.org/mailman/listinfo/libpqxx-general
