Error reporting mechanism for os.watch

[utgheith]

os.watch.watch has 2 distinct phases: (1) recursively scan the watched paths, (2) fork a thread that listens for notifications and reports them back by calling on onEvent function.

Some (but not all) of the errors occurring caught during the second phase print a stack trace and terminate the watcher without informing the caller.

Source of errors:

• overflow: the underlying watch mechanism usually has an in-kernel buffer that might overflow. Both Linux and OSX report those back as overflow events indicating loss of information.
• Resource limits: too many open files, etc.
• Yanking an external drive
• Changing permissions
• ...

My use case for os.watch restarts itself every 5 minutes to compensate for lack of reliable error reporting

The proposed API changes (should be backwards compatible with existing code)

• Add a 3rd callback to os.watch.watch( onError: WatchError => ErrorResult)
• Add a sealed trait for different kinds of errors (WatchError)
• Add a sealed trait for error responses (ErrorResult)
• Add a default error handler (defaultHandler) that behaves like the current implementation

Issues:

• Ordering between events and errors is harder to establish then if the same callback handled both. Doing this would change the API in a non-backwards compatible way