Closed domenkozar closed 3 years ago
Hmm, what would you want to happen @domenkozar ?
If we wanted to rethrow the exception I'm not sure which thread to throw to, since file events happen asynchronously in response to callbacks from the OS.
It seems like the API would need to be extended to provide another callback or something to use in case of exception.
Or we could leave it as-is and mention in the documentation that actions need to be wrapped in handlers if exceptions are a possibility.
I think the sane default is to provide a setting like SomeException -> IO ()
with the default implementation printing the event and exception that occoured.
Just spent some time trying to track down why my watches were stopping; it never occurred to me that if my Action
threw an exception, then the watcher would quietly stop running. I don't have much opinion on how the library ought to report exceptions, but I think it certainly should at least catch them and not enter a failure state.
@chris-martin I haven't seen that it would enter a failure state, but rather just swallow exceptions from actions.
This is fixed in master
now and will be released as part of 0.4.0.0
. (Implemented a user-configurable handler as @domenkozar suggested.)
@thomasjm any plans to release 0.4.0.0?
Hey, sorry for the delay @domenkozar. The only blocker for 0.4.0.0 is that one of the breaking changes is ripping out the flawed old debounce mechanism, and replacing it with something based on this suggestion: https://github.com/haskell-fswatch/hfsnotify/issues/55#issue-56087472.
You can see the half-done version here: https://github.com/haskell-fswatch/hfsnotify/blob/master/src/System/FSNotify/Debounce.hs.
I suppose we could ship 0.4.0.0 with no debounce capability at all (probably better than the status quo tbh) and add it later, if people badly want the current version.
If
Action
throws an exception, it just gets ignored.