Path: csiph.com!usenet.pasdenom.info!news.redatomik.org!newsfeed.xs4all.nl!newsfeed2a.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <87egltht87.fsf@Equus.decebal.nl>
References: <87egltht87.fsf@Equus.decebal.nl>
Date: Wed, 3 Jun 2015 23:29:02 +1000
Subject: Re: Retrying to send message
From: Chris Angelico <rosuav@gmail.com>
Cc: "python-list@python.org" <python-list@python.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.108.1433338144.13271.python-list@python.org>
Lines: 52
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:91962

On Wed, Jun 3, 2015 at 10:27 PM, Cecil Westerhof <Cecil@decebal.nl> wrote:
>     def send_message(account_id, message, max_tries, terminate_program):
>         error_msg   =3D 'Something went wrong with: ' + message
>         not_send    =3D True
>         tries       =3D 0
>         while not_send:
>             try:
>                 Core().update_status(account_id, message)
>             except libturpial.exceptions.ServiceOverCapacity:
>                 tries +=3D 1
>                 print('Tried to send it {0} times'.format(tries))
>                 if tries >=3D max_tries:
>                     terminate_program(error_msg)
>                 time.sleep(60)
>             except:
>                 terminate_program(error_msg)
>             else:
>                 not_send =3D False
>
> Is this a reasonable way to implement this, or is another way better?
> Well, maybe the timeout should be a parameter also. ;-)

I'd skip the not_send flag and do the logic thusly:

while True:
    try:
        update_status as above
        break
    except ServiceOverCapacity:
        as above

And I'd also skip the bare except clause. If you get any sort of
exception, whether it's a bug, a failure from libturpial, a network
error, or anything else, your code will just terminate with a bland
and useless message. Much better to simply let the exception bubble
up.

> Also the documentation of time.sleep says:
>     The actual suspension time may be less than that requested because
>     any caught signal will terminate the sleep() following execution
>     of that signal=E2=80=99s catching routine.
>
> My program does not much else as sending the message. So I think it is
> not necessary to cover for this possibility. Are I assuming to much?

I wouldn't worry too much about a signal cutting your sleep short; it
doesn't look to me as if "exactly sixty seconds" is all that crucial
here. If your program sleeps for 42.645 seconds and then gets woken up
by a signal, and you retry a bit sooner than you otherwise would have,
is it going to break anything? If not, just ignore that possibility.

ChrisA