errors

Errors

Errors handling with logs

Multiple workers does not help. We need an advanced error handling to get logs right.

Currently, when the exceptions are raised in a worker they might be automatically propagated to other workers with the edmp module.

This allows to raise the exception in another worker but this feature remains basic and might fail to raise the exact same error. Sadly, pickling of stack traces is not possible.

For the same reasons, exposing the error handling to the rascal is not a possible in a generic way. This is probably not what we want.

I can think of two ways to improve this:

• Turn the stack trace into text and propagate this so it wan be written in the logs where appropriate.
• Enable each worker to write its own logs.

I tend to think that the latter is the best approach. In this case, we might use namespaces like path/to/logs/<run-ID>/<worker-name>.log.

Also, errors are lost in the output of the run. In offlineimap we duplicate the errors at the end of the run. If we have logs on disk we could print a warning like "errors happened in the run, try 'imapfw errors show '" to know more.

• Support per-run logs for errors.
• Support per-worker logs for errors.
• Implement the errors action.
  • Implement errors --list to list the errors stored on disk.
  • Implement errors --show <run-iD> to show the errors from this run.
  • Implement errors --delete <run-iD> to remove those errors.
  • Implement errors --report <run-iD> to well-format errors for the issue tracker. If errors --show is good enough, this might be used for this prupose, too.

Improved errors

• Add context to errors (like previous requests to drivers).
• Embedd the rascal to the errors (remove private data).
• Fine-grained tuning. Users might want different way to handle errors (from very basic to advanced) depending on what gets done (actions, CLI options, accounts, etc).