Bug 825289

This is an exception that should be catched in python-fedora.

Couple things:

1) You're using an older version of python-fedora.  The current version uses python-requests rather than pycurl so you won't see this particular traceback with the current package in Fedora.  The latest version of python-fedora is python-fedora-0.3.32.3-1.fc17 -- be sure that you have an updated python-requests as well since earlier versions of python-requests were buggy.  The latest f17 version of that is: python-requests-1.1.0-3.fc17

2) This error should be caught at the fedora-easy-karma level, not the python-fedora level.  This is an error from the request to the server that python-fedora can't recover from therefore it's up to fedora-easy-karma to decide what to do with it.

(In reply to Toshio Ernie Kuratomi from comment #2)
> Couple things:
> 
> 1) You're using an older version of python-fedora.  The current version uses
> python-requests rather than pycurl so you won't see this particular
> traceback with the current package in Fedora.  The latest version of
> python-fedora is python-fedora-0.3.32.3-1.fc17 -- be sure that you have an
> updated python-requests as well since earlier versions of python-requests
> were buggy.  The latest f17 version of that is: python-requests-1.1.0-3.fc17

The bug report is old, therefore an older version was used.

> 2) This error should be caught at the fedora-easy-karma level, not the
> python-fedora level.  This is an error from the request to the server that
> python-fedora can't recover from therefore it's up to fedora-easy-karma to
> decide what to do with it.

IMHO python-fedora should raise a BodhiClientException instead of an exception depending on the underlying request abstraction, then f-e-k can easily except it.

I used to think that as well but changed my mind after reading

http://plope.com/Members/chrism/now_not_to_write_python

and 

http://blog.ianbicking.org/2007/09/12/re-raising-exceptions/

and seeing the exceptions portion of this talk:

http://pyvideo.org/video/880/stop-writing-classes

This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

(In reply to Toshio Ernie Kuratomi from comment #4)
> I used to think that as well but changed my mind after reading
> 
> http://plope.com/Members/chrism/now_not_to_write_python
> 
> and 
> 
> http://blog.ianbicking.org/2007/09/12/re-raising-exceptions/
> 
> and seeing the exceptions portion of this talk:
> 
> http://pyvideo.org/video/880/stop-writing-classes

This does not really convince me, as the exception that was raised appears to come from pycurl and would not be raised anymore and there is no comment which exceptions BodhiClient.query() is supposed to raise, even if they come from other modules. Can you please give an example how you would use the method according to the ideas from the posted URLs?

It depends on what you want to do.  It sounds like you want to catch all errors that may be thrown from this function.  So:

try:
    testing_updates = bc.query(release=release, status="testing", limit=1000)["updates"]
except Exception as e:
    do_stuff()

Do you actually have a way to handle this specific exception and recover gracefully instead?

If the exception indicates a transient network error, then I would just retry bc.query(), e.g. up to three times. If it is a permanent error, printing a descriptive error message and just quitting would be the way to go.

try:
    testing_updates = bc.query(release=release, status="testing", limit=1000, retries=3)["updates"]
except Exception as e:
    print_descriptive_error()

(Note: you could also set bc.retries=3 to make that the default for all bc actions if you want.)

(In reply to Toshio Ernie Kuratomi from comment #9)
> try:
>     testing_updates = bc.query(release=release, status="testing",
> limit=1000, retries=3)["updates"]
> except Exception as e:
>     print_descriptive_error()
> 
> (Note: you could also set bc.retries=3 to make that the default for all bc
> actions if you want.)

It looks like bc.query() does not support a retries parameter on Fedora 19. Also I changed it to

try:
    testing_updates = bc.query(release=release, status="testing", limit=1000)
except Exception as e:
    print "Cannot query Bodhi: {0}".format(e)
    sys.exit(1)
else:
    testing_updates = testing_updates["updates"]

to at least not mask a potential KeyError for "updates", but it does not really feel clean, because e.g. this also masks errors that would result from a change to Bodhi's API and therefore making the client fail. Therefore ther should IMHO be an easy way to distinguish permanent from transient errors.

fedora-easy-karma-0-0.19.20130707git121694f6.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/fedora-easy-karma-0-0.19.20130707git121694f6.fc19

fedora-easy-karma-0-0.19.20130707git121694f6.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/fedora-easy-karma-0-0.19.20130707git121694f6.fc18

(In reply to Till Maas from comment #10)
> (In reply to Toshio Ernie Kuratomi from comment #9)
> > try:
> >     testing_updates = bc.query(release=release, status="testing",
> > limit=1000, retries=3)["updates"]
> > except Exception as e:
> >     print_descriptive_error()
> > 
> > (Note: you could also set bc.retries=3 to make that the default for all bc
> > actions if you want.)
> 
> It looks like bc.query() does not support a retries parameter on Fedora 19.

Yeah, i was thinking incorrectly.  You'll need to use bc.retries=3

send_request() which every call to the server is built on supports setting retries at the time of the call.  But individual methods that call the server have the option not to support every parameter that send_request() does.

> Also I changed it to
> 
> try:
>     testing_updates = bc.query(release=release, status="testing", limit=1000)
> except Exception as e:
>     print "Cannot query Bodhi: {0}".format(e)
>     sys.exit(1)
> else:
>     testing_updates = testing_updates["updates"]
>
Note:  There's no need for an else: there.  You can simply set testing_updates = testing_updates["updates"] after you exit the try: except:
 
> to at least not mask a potential KeyError for "updates", but it does not
> really feel clean, because e.g. this also masks errors that would result
> from a change to Bodhi's API and therefore making the client fail. Therefore
> ther should IMHO be an easy way to distinguish permanent from transient
> errors.

Distinguishing transient from permanent errors won't help you with that case (API changes are a type of permanent error...).  And transient errors that are repeatable X number of times (via retries) seem to fall into the same error handling as permanent errors in your use case....

I'm not sure that misuse of the API can be distinguished from other errors either... For some methods, especially generic methods ("query()" sounds like such a method although lmacken wrote it, not I)  the user is allowed to pass strings in that border on arbitrary.  These are passed on to the server which sanitizes them and then tries to do something sensible with them.  But the attempt may cause a traceback on the server.  This would be indistinguishable from a traceback caused by a bug in the server code.  (Equally, if the strings that were given, say as a simple enum replacement, were to change, sending bad enums might simply make the server return empty data sets rather than throwing an error).

If you're simply worried that bc.query might go away, you can check for a NameError exception before your catch-all exception.

(In reply to Toshio Ernie Kuratomi from comment #13)
> (In reply to Till Maas from comment #10)
> > (In reply to Toshio Ernie Kuratomi from comment #9)

> > Also I changed it to
> > 
> > try:
> >     testing_updates = bc.query(release=release, status="testing", limit=1000)
> > except Exception as e:
> >     print "Cannot query Bodhi: {0}".format(e)
> >     sys.exit(1)
> > else:
> >     testing_updates = testing_updates["updates"]
> >
> Note:  There's no need for an else: there.  You can simply set
> testing_updates = testing_updates["updates"] after you exit the try: except:

Thank you, I changed it.

> > to at least not mask a potential KeyError for "updates", but it does not
> > really feel clean, because e.g. this also masks errors that would result
> > from a change to Bodhi's API and therefore making the client fail. Therefore
> > ther should IMHO be an easy way to distinguish permanent from transient
> > errors.
> 
> Distinguishing transient from permanent errors won't help you with that case
> (API changes are a type of permanent error...).  And transient errors that
> are repeatable X number of times (via retries) seem to fall into the same
> error handling as permanent errors in your use case....

For me, typical transient errors, that should not create a traceback are IOErrors, e.g. because the network connections is buggy, the server is down etc.
Permanent errors that should case a traceback would be code errors in python-bugzilla or if bc.query() would not accept the parameters I specified.

> I'm not sure that misuse of the API can be distinguished from other errors
> either... For some methods, especially generic methods ("query()" sounds
> like such a method although lmacken wrote it, not I)  the user is allowed to
> pass strings in that border on arbitrary.  These are passed on to the server
> which sanitizes them and then tries to do something sensible with them.  But
> the attempt may cause a traceback on the server.  This would be
> indistinguishable from a traceback caused by a bug in the server code. 

Whether or it it can be distinguished depends on how the server reports each kind of traceback.

Package fedora-easy-karma-0-0.19.20130707git121694f6.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing fedora-easy-karma-0-0.19.20130707git121694f6.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-12590/fedora-easy-karma-0-0.19.20130707git121694f6.fc18
then log in and leave karma (feedback).

fedora-easy-karma-0-0.19.20130707git121694f6.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

fedora-easy-karma-0-0.19.20130707git121694f6.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.