Report-errors in emitter

[earonesty]

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).

[CCP-Aporia]

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]

Thank @tommorris!

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!

[BoboTiG]

Suggested change

	self.queue_event(FileObserverErrorEvent(self._watch.path, ex))
	self.queue_event(FileObserverErrorEvent(self._watch.path, ex))
	# Prevent circular reference
	ex = None
	del ex

[BoboTiG]

Suggested change

	self._exception = exception
	super(FileObserverErrorEvent, self).__init__(src_path)
	super().__init__(src_path)
	self._exception = exception

[tommorris]

@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.)

[BoboTiG]

@tommorris my bad, sorry for the false alert :)

[BoboTiG]

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 ⬆️

[pbrackin]

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: #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?