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

[Future] Exception handling with Future::then() #104

Open
bkotsopoulossc opened this issue Aug 29, 2022 · 0 comments
Open

[Future] Exception handling with Future::then() #104

bkotsopoulossc opened this issue Aug 29, 2022 · 0 comments
Assignees

Comments

@bkotsopoulossc
Copy link
Contributor

Problem

If we call .then() on a djinni future, it returns a promise. If the handler function passed into then() throws, the exception is caught and used to reject the promise returned from then() here.

This works great for cases like this, as the exception is propagated in the returned future:

djinni::future<int> foo() {
  return someAsyncThing().then([](incomingFuture) {
    auto value = incomingFuture.get();
    if (value > 10) {
      throw std::runtime_error("failed");
    }

    return value ? XX : YY;
  });
}

Sometimes though, for better or worse, djinni futures are used like this. And if an exception is thrown in this handler function, it doesn't propagate as well:

djinni::future<int> foo() {
  promise<int> promise;
  auto future = promise.get_future();
  someAsyncThing().then([promise](incomingFuture) {
    auto value = incomingFuture.get();
    if (value > 10) {
      throw std::runtime_error("failed");
    }

    promise->setValue(value ? XX : YY);
  });

  return future;
}

In this case, even though the thrown exception is caught, the new promise returned by then() is not actually used.

Potential Solutions

Can we either add some sort of API to allow this pattern to work, or add some attributes that prevent the user from writing code like this?

  • Would we want .then() to return [[nodiscard]]? Are there cases where we don't want to do anything with the return value? What would be the opt-out path? std::ignore or void-cast or something?
  • Would we want to add a way for the caller to register the outer promise with the then() call, so the runtime can resolve the outer promise rather than create a new one? .then(Callbable&& callable, Promise<T> outerPromise) maybe?
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