Hi all, I am porting an application previously written using a little-known framework called Kaa [1] to Tulip. There are a couple areas of surprise around cancellation that I wanted to ask about:
1. Cancellations are silent. Normally unhandled asynchronous exceptions are logged by the default exception handler. Cancellations appear to be exempt, and although CancelledError of a subtask does bubble up through the call stack, unlike other uncaught asynchronous exceptions, logging is suppressed. I find this surprising. Now that surprise could just be that with Kaa I made a conscious design decision that cancellations must be explicitly caught and uncaught cancellations would be noisy. I think this fits better with Python's zen (notably explicit is better than implicit). Was silent cancellation a specific design choice with tulip? 2. Custom cancellation exceptions are impossible. One feature of kaa that I use in my application is the ability to abort (or cancel, in tulip's lingo) a coroutine with a custom exception. [2] This lets the canceller pass information into the coroutine and up the stack about why the coroutine was cancelled. In my particular use case, I have a notion of a soft abort and a hard abort, which triggers different logic by a coroutine higher up the stack. An outside observer task which tracks overall progress will either do a hard or soft abort depending on some condition. I'd propose something similar to what Kaa does: be able to pass an optional custom exception object to cancel() which is raised inside the coroutine and up the stack. The custom exception would need to subclass CancelledError. Thoughts? I am happy to submit a patch if there's agreement that this is a good idea. (Obviously I think it is. :)) Thanks! Jason. [1] http://api.freevo.org/kaa-base/index.html [2] http://api.freevo.org/kaa-base/async/inprogress.html#kaa.InProgress.abort
