watchdog
watchdog copied to clipboard
gorakhargosh
Report-errors in emitter
Emitters can raise exceptions, for example if a handle becomes invalidated. Rather than handle it on a per-emitter basis, a catch-all can emit the underlying exception.
The caller can then choose to tear down an observer, or ignore the event as needed.
DRAFT: Does this look reasonable? Should I keep going (tests, use cases, docs).
Thanks for investigating this. IMHO having an error event can be useful for consumers to notice that the observer or emitter they are relying upon may need to be re-created.
Unfortunately not all emitters are using the same run() implementation, and some even need to go a bit further in their implementation in order to catch exceptions (f.e. the callback method specified in the FSEventsEmitter). However, this is a good start and shows other implementors that it is important to catch exceptions in run(). :-)
@BoboTiG I'm not sure I'm involved in this PR at all. (I did make a PR for this project back in 2014: #242 but nothing since then.)
I like the event idea, I think you can move forward (and sorry for the delay).
It is an important change, so if you can add tests, some documentation, and a line + your GitHub nickname in the changelog, that would be awesome!
@earonesty :arrow_up:
I am trying to use watchdog to monitor a NAS CIFS share from a windows VM as a windows service. It works well for a while but eventually I see that the observer thread dies with no information a la: https://github.com/gorakhargosh/watchdog/issues/663
This seems to be getting at a way to figure out the cause of that thread death which seems like a good idea. I wonder, how would one use this when subclassing PatternMatchingEventHandler? Do we need to first add the EVENT_TYPE_ERROR to the FileSystemEventHandler dispatch so that we can trap the event (eg, "on_error") and dump its repr?
