J'essaie de comprendre comment utiliser l'erreur de manipulation correcte dans Python. Je suis surtout sur WatchDog pour regarder mes foleurs dans un disque connecté au réseau. Somethimes le disque dissocie sous peu, puis se connecte à nouveau et une erreur apparaît. "Exception dans le fil thread-2:"
J'ai un lien d'erreur, mais je ne suis pas sûr que je le fais correctement. P>
devrais-je mettre un autre essai à l'observateur.schedule? P>
Python 3.6, Windows 10 P>
if __name__ == '__main__':
path = "P:\\03_auto\\Indata"
observer = Observer()
observer.schedule(MyHandler(), path, recursive=True)
observer.start()
try:
while True:
time.sleep(1)
except KeyboardInterrupt:
observer.stop()
observer.join()
3 Réponses :
Eh bien, le juger par un coup d'œil rapide à la source, Tous les observateurs semblent hériter de leur edit: sys.excepthook L'approche que j'ai mentionnée dans mon commentaire n'est pas réalisable pour le moment. Il y a plus d'une décennie ancienne Bug qui rend les fils dérivés de filetage.thread Ignorer sys.excepthook . Il existe des solutions de contournement dans le fil du message de ce bogue, mais je suis hestiant de poster une réponse à utiliser une solution de contournement, d'autant plus que ce bogue semble enfin obtenir une solution pour Python 3.8. L'autre option serait dériver un observateur personnalisé de l'observateur de Watchdog.
La manière la plus élémentaire que je puisse penser est une enveloppe autour de la méthode exécuter de eventdispatcher.run () , vous pourriez peut-être même omettre le wrapper et répertorier cette méthode directement OSError * par quelle que soit la classe d'exception reloise réellement dans votre cas :)
* Selon le commentaire de @ Henryyik ci-dessous, un lecteur de réseau déconnectant, semble élever un OsError (WinError 64: error_netName_Deletted) sur les systèmes Windows. Je trouve qu'il est probable que le style UNIX OSS augmente le même type d'exception dans cette situation, alors j'ai mis à jour les extraits de code pour utiliser maintenant Oserror au lieu du Filenotfounderror J'ai utilisé à l'origine.
Juste pour référence, j'étais dans une situation similaire en tant que OP et j'ai reçu un Oserror (WinError 64) lorsque mon lecteur de réseau s'est déconnecté pendant un certain temps.
@Henryyik merci! J'ai ajouté cette information à ma réponse.
Malheureusement, j'ai essayé votre solution et obtenez toujours l'Oserror Winerror64 lorsque mon lecteur réseau déconnecte. Semble ne pas attraper l'erreur au bon endroit
@Henryyik je pouvais seulement passer à l'assomption ici. Le poste de l'OP n'apporte ni quelle exception augmente, ni exactement dans le code, cela le fait. Vos commentaires n'ont malheureusement pas également d'aide pour identifier la source exacte de la question. Veuillez créer une question avec un MCVE et la Traceback complet de Peope pour regarder.
Je pense ci-dessous est ma réponse.
J'ai terminé le test. P> super (). Exécuter () code> n'est pas une bonne réponse.
J'ai essayé beaucoup de choses avec la réponse de Shmee, mais ce n'était pas concret et sans signification. from watchdog.observers import Observer
from watchdog.events import PatternMatchingEventHandler
class Watcher :
def __init__(self):
self.observer = Observer()
print('observer init...')
def run(self):
global osv_status
try :
event_handler = MyHandler(patterns=["*.txt"])
self.observer.schedule(event_handler, Directory, recursive=True)
self.observer.start()
osv_status = 1
except OSError as ex:
print("OSError")
time.sleep(.5)
if self.observer.is_alive() is True:
self.observer.stop()
self.observer.join()
print("Observer is removed [ ",osv_status," ]")
osv_status = 2
except Exception as ex:
self.logger.exception("Exception ex :{0} ".format(ex))
class MyHandler(PatternMatchingEventHandler):
def __init__(self,*args, **kwargs):
super(MyHandler, self).__init__(*args, **kwargs)
print("MyHandler Init")
def on_created(self, event):
print('New file is created ',event.src_path)
except Exception as ex:
self.logger.exception("Exception ex :{0} ".format(ex))
def on_modified(self,event):
print('File is modified ',event.src_path)
try :
doing()
except Exception as ex:
self.logger.exception("Exception ex :{0} ".format(ex))
if __name__ == "__main__":
.....
osv_status = 0 # 0: ready, 1:start 2: halt
wch =Watcher()
wch.run()
try :
while(1):
if is_Connect == False:
sock_connect()
print('sock_connect')
time.sleep(1)
if os.path.exists(Directory) is False and osv_status == 1:
wch.observer.stop()
wch.observer.join()
print("Observer is removed [ ",osv_status," ]")
osv_status = 0
elif os.path.exists(Directory) is True and (osv_status == 0 or osv_status == 2):
if wch.observer.is_alive() is False:
wch =Watcher()
wch.run()
Cet important concept est en train de retirer l'observateur. Lorsque l'observateur est vivant, un autre observateur reliant la halte de l'arrêt afin de gérer le statut d'observateur.
J'ai aussi posté ceci dans un thread lié ici
Voici comment j'ai résolu ce problème: < / p> sous-classement Utilisez windowsapiemitter pour attraper l'exception dans wheee_events . Afin de continuer après la reconnexion, WatchDog a besoin de ré-régler la poignée de répertoire, que nous pouvons faire avec self.on_thread_start () . myemitter avec baseobserver , nous pouvons maintenant gérer la perte et la reprise de la connexion à des lecteurs partagés.
L'exception levée à l'intérieur du fil, vous devez manipuler des erreurs là-bas, probablement dans la méthode
START () .Merci. Donc, si je fais cela: Essayez: Observateur.start () Sauf: Imprimez («Det Har Blivit Något Fel») si sauf s'agit de jouer, mon script s'arrêtera? Dois-je faire une sorte de boucle som pour que cela continue à numériser? Ou Watchdog prend-il en charge cela?
Oh,
Observer fait partie d'un package tiers. Je ne savais pas. Cela rend un peu plus difficile. Manipulation des exceptions autour deObserver.Start () ne vous aidera pas comme l'exception provient d'un autre thread et est donc sur une autre pile. Les solutions possibles peuvent être le sous-classementObserver pour prolonger sa manipulation d'exception ou écrasersys.excepthook . Je vais jouer avec des approches et les décrire dans une réponse. Pourrait prendre un peu cependant, il est à propos de l'heure du déjeuner :)