Que diriez-vous de réduire la granularité du try-catch ? Ou collez votre code pour analyse. Ce que vous avez dit sur la poursuite de l'exécution du code d'origine après une exception est un peu vague.
【Modifier】 Après avoir lu les deux autres réponses, ce sont essentiellement les deux idées que j'ai avancées dans les commentaires ci-dessous. Il faut dire que les idées de chacun sont fondamentalement les mêmes. Modifiez ici et donnez-moi un plan de code :
# introduce a new function
# @return: succeed, new_ip
def exec(ip, url):
try:
# do what you want to do
return True, ip
except:
# change your id
return False, new_ip
# your original logics
urls = [url1, url2, ..., url10]
i = 0
ip = ip1
while i <= len(urls):
succeed, ip = exec(ip, urls[i])
if succeed:
i +=1
Je viens d'en écrire un, qui génère Access Token est le seul Access Token dans la base de données , mais la fonction qui génère ne peut pas garantir que le Access Token généré à chaque fois est le pareil. Pas pareil. J’ai donc utilisé une boucle Access Token vraiment dégoûtante. C'est à peu près comme suit : while
while True:
try:
access_token = make_token()
access_token.add_to_db
break
except IntegrityError as e:
if e.orig.args[0] == 1062:
# 这种情况下,发生了mysql 1062异常,说明数据库中有重复的access token,需要反复生成新的,直至不同
pass
else:
raise e
Pas malin, mais ça marche.
Ou parlez-moi de votre entreprise, ce ne sera peut-être pas si dégoûtant.
Texte original de la question : C'est un peu plus gênant pour moi. Par exemple, je dois demander 10 URL dans l'ordre. Si la cinquième URL est déconnectée, une erreur sera signalée, puis je le ferai. exécutez le code pour changer l'IP ci-dessous sauf qu'il est impossible d'écrire un certain temps pour chaque requête. C'est tout simplement inesthétique.
Mon forfait :
def r(uri, data):
while True:
try:
res = requests(uri, data)
return res
except:
change_ip()
Cette solution devrait être possible pour les demandes de synchronisation à processus unique et à thread unique.
Que diriez-vous de réduire la granularité du try-catch ? Ou collez votre code pour analyse. Ce que vous avez dit sur la poursuite de l'exécution du code d'origine après une exception est un peu vague.
【Modifier】
Après avoir lu les deux autres réponses, ce sont essentiellement les deux idées que j'ai avancées dans les commentaires ci-dessous. Il faut dire que les idées de chacun sont fondamentalement les mêmes. Modifiez ici et donnez-moi un plan de code :
Je viens d'en écrire un, qui génère
Pas malin, mais ça marche.Access Token
est le seulAccess Token
dans la base de données , mais la fonction qui génère ne peut pas garantir que leAccess Token
généré à chaque fois est le pareil. Pas pareil. J’ai donc utilisé une boucleAccess Token
vraiment dégoûtante. C'est à peu près comme suit :while