On 2015-06-03 17:15, Cecil Westerhof wrote:
Op Wednesday 3 Jun 2015 15:29 CEST schreef Chris Angelico:
On Wed, Jun 3, 2015 at 10:27 PM, Cecil Westerhof <ce...@decebal.nl> wrote:
def send_message(account_id, message, max_tries,
terminate_program): error_msg = 'Something went wrong with: ' +
message not_send = True tries = 0 while not_send: try:
Core().update_status(account_id, message) except
libturpial.exceptions.ServiceOverCapacity: tries += 1 print('Tried
to send it {0} times'.format(tries)) if tries >= max_tries:
terminate_program(error_msg) time.sleep(60) except:
terminate_program(error_msg) else: not_send = 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
Yes that is much better. I now made it:
def send_message(account_id, message, max_tries, give_error, wait_time =
60):
error_msg = 'Something went wrong with: ' + message
tries = 0
while True:
try:
Core().update_status(account_id, message)
break
except libturpial.exceptions.ServiceOverCapacity:
tries += 1
print('Tried to send it {0} times'.format(tries))
if tries >= max_tries:
give_error(error_msg)
return
time.sleep(wait_time)
except:
give_error(error_msg)
return
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.
I kept the except. I like to see the message that went wrong. ;-)
You're still swallowing unexpected exceptions.
If any exception apart from ServiceOverCapacity is raised, the bare
except will just call 'give_error' and then return.
If you try to interrupt the program (^C on Windows, ^D on Linux), that'll
also be ignored.
Also, in my case give_error terminates the program, but it never hurts
to make functionality generic, so I added return statements. Not
break, because on error you should leave the function. Break would in
this instance do the same, but I find this neater.
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’s 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.
Correct, so I did not assume to much. :-D
Usually I check parameters. But I understood that is not the Python
way. For example a wait_time of 1, or negative is not useful. Also a
max_tries of 10 ** 12 would not be very useful. But I can put the
burden of the problem on the caller of the function?
--
https://mail.python.org/mailman/listinfo/python-list
