Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support contextbacks #34

Open
vmalloc opened this issue Apr 11, 2018 · 1 comment
Open

Support contextbacks #34

vmalloc opened this issue Apr 11, 2018 · 1 comment
Assignees
Milestone

Comments

@vmalloc
Copy link
Member

vmalloc commented Apr 11, 2018

The usage should be something like:

operation_context = gossip.define_contextback('name', args=(...), tags=..., ....)

And then for registration

@operation_context.register
@contextmanager
def my_contextmanager(arg1, arg2):
     ...
     yield
     ....
@vmalloc vmalloc added this to the 2.4.0 milestone Apr 11, 2018
@vmalloc
Copy link
Member Author

vmalloc commented Jan 13, 2019

A few questions that are raised, assuming the syntax is something like:

@infinisdk.hooks.object_deletion.register
@contextmanager
def some_contextback():
    before()
    try:
        yield
    except:
        error()
    else:
        after()
  1. How does exception handling work? We need to define the meaning of ignore, raise defer, and raise immediately in these cases. The easiest thing to do is make ignore completely ignore, and the others meaning we cancel all entered contexts and then raise
  2. How do we handle contextbacks that swallow exceptions? It sounds dangerous to just allow it, because it will hurt other registrations on the way
  3. The result of the yield statement, as well as what it yields, will have no semantics whatsoever -- any information passed to or from the contextbacks will be done solely via arguments
  4. Provides/needs in the define phase, will hold only for the begin phase of the contextback
  5. Attempting to call wait_for after the context has been entered, needs to result in a RuntimeError

Intuitively, the exception policies should apply for the enter phase, as once an enter is completed successfully, the exit must be called anyway for consistency. This means that exit can be thought of as always being "raise deferred".
We can also deceide that the cleanup exception priority is also dictated from the exception policy:

  1. If the policy is ignore, we ignore exceptions in the handler exits completely
  2. A raise immediately policy raises the latest handler exception immediately, meaning exceptions mask one another
  3. A raise defer policy raises the first available exceptions, including the wrapped operation's exception

The policy defaults might be different between regular hooks and contextbacks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants