J'ai l'impression de comprendre un peu la gestion des exceptions, qui était un mystère lorsque j'apprenais Java. S'il y a un apprenant qui dit: «Le mérite de gérer les exceptions est un mystère», j'espère que cela sera utile comme exemple de la façon dont la gestion des exceptions peut être utilisée.
Au cours de l'élaboration de ce programme, j'ai appris la gestion des exceptions. Langue: Python3 Résumé: Surveillez automatiquement le taux de la monnaie virtuelle de Zaif Bibliothèque: GitHub --techbureau / zaifapi (Merci)
Ce que j'ai fait, c'est la même chose que de regarder le site officiel de Zaif. Connectez-vous simplement à Zaif via l'API et entrez les informations sur le taux de change.
# -*- coding: utf-8 -*-
from zaifapi import ZaifPublicApi
zaif = ZaifPublicApi()
#Répéter 10 fois
for i in range(10):
while (1):
err = False
try:
askBJ = zaif.depth('btc_jpy')['asks'][0][0]
askMJ = zaif.depth('mona_jpy')['asks'][0][0]
askMB = zaif.depth('mona_btc')['asks'][0][0]
bidBJ = zaif.depth('btc_jpy')['bids'][0][0]
bidMJ = zaif.depth('mona_jpy')['bids'][0][0]
bidMB = zaif.depth('mona_btc')['bids'][0][0]
except:
err = True
print('except')
if (err == False):
break
print(askBJ, end=', ')
print(askMJ, end=', ')
print(askMB, end=', ')
print(bidBJ, end=', ')
print(bidMJ, end=', ')
print(bidMB)
Si une erreur de connexion se produit lors du traitement dans l'essai du programme ci-dessus, l'occurrence de l'exception est détectée et le traitement en sauf est effectué, et l'essai est répété sans quitter la boucle. En d'autres termes, «Si vous faites une erreur de connexion, reconnectez-vous» est répété jusqu'à ce que la connexion réussisse.
De mon point de vue, ces trois points sont les bons points de gestion des exceptions.
C'est une vue biaisée, mais si vous entourez la partie où l'exception se produit dans try, elle ne tombera pas même si vous passez (ne faites rien) avec except. Les exceptions ignorées se propageront et provoqueront une erreur ailleurs ... Si cela se produit, cela finira par tomber, mais avec le programme ci-dessus, seule une erreur de connexion se produira, donc cela durera.
Je ne savais pas cela dans le passé, alors j'ai vraiment pensé que l'exception était «un diable mystérieux qui essaie sans relâche d'abandonner le programme».
[PostScript 2018/2/5] Il semble qu'il y avait une personne similaire
Le sous-traitant développeur de SIer n'est-il pas trop bas? Je ne comprends pas ce que fait le framework ou la bibliothèque ~ Omis ~ Ces personnes ne comprennent généralement pas du tout les «exceptions». Je ne sais pas à quoi cela sert, et je reconnais seulement que cela interfère avec mon travail de codage.
try {
...
}catch(Exception e) {
return false;
}
Vous pouvez écrire ce type de code pour presser les informations d'erreur.
C'est certainement le cas de mon exemple, et je ne peux pas m'empêcher car les contre-mesures consistent à «faire disparaître».
Pour faire une excuse, dans mon cas c'est OK si je me reconnecte, donc je pense que c'est encore mieux.
Bref, sauf à travers dans le sens où «je veux que tu te reconnectes silencieusement, mais ne tombe pas un par un».
Bien sûr, si vous ne prenez pas le contenu d'exception, vous ne pourrez pas trouver d'exceptions telles que «En fait, la clé API est différente» ou «Il n'y a pas de telle paire de devises», elle sera donc disponible à long terme.
Comment écrire la gestion des exceptions qui pose problème pour les opérateurs Lorsqu'une erreur se produit dans le système, l'opérateur regarde la sortie du journal du programme et identifie la cause. La gestion des exceptions est importante pour le moment. _ Avec une gestion correcte des exceptions, il sera plus facile d'identifier la cause. _
Même dans ce programme, je souffrais de l'erreur Exception: le code d'état de retour est 504 pendant un certain temps avant qu'il ne soit terminé. En fait, à ce stade, on m'a dit que le problème était une erreur 504, donc je suis finalement arrivé à "Si vous n'arrêtez pas d'essayer de vous connecter jusqu'à ce que ça passe".
S'il ne s'agit pas d'une exception et que le message "le type de variable est différent" _ Pourquoi le type est-il différent? Débogage → Pourquoi n'y a-t-il pas de problème orz → Si vous le tournez pendant un certain temps, la même erreur se produit parfois → Les données reçues sont dans le désordre dans la partie communication, est-ce le type différent? _
J'ai enfin compris la cause, et plus loin _ Pourquoi y a-t-il des moments où c'est normal et des moments où c'est fou? → Cela semble arriver régulièrement → De votre côté? L'autre fête? → Le serveur de l'autre partie est-il en panne? _
J'ai l'impression de remarquer l'erreur 504 pour la première fois ici (l'exemple peut être mauvais).
L'exception est qu'il ignore un tel processus et vous dit immédiatement "J'ai eu une erreur 504".
Si vous utilisez la gestion des exceptions, vous pouvez traiter «le même problème à la racine» comme la même exception quels que soient les détails. Même si vous essayez de passer le type str au type int ou vice versa, le problème que les types de variables sont différents est le même, donc même si vous n'écrivez pas deux instructions if, elles sont résumées dans TypeError comme une exception (l'exemple peut être mauvais) inconnue).
Si vous étendez cela, vous pouvez écrire un push comme "S'il y a un problème, une exception se produira. Si une exception se produit, tout le traitement des exceptions sera terminé!"
Dans la bibliothèque utilisée cette fois, il y a une section qui la traite intentionnellement comme une exception lorsqu'une valeur étrange est détectée (je pense que l'erreur 504 est le cas). Cela a l'air un peu sympa car cela ressemble à un mécanisme efficace dont l'utilisateur n'a pas à se soucier des détails.
Recommended Posts