You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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:
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:
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?
.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?then()
call, so the runtime can resolve the outer promise rather than create a new one?.then(Callbable&& callable, Promise<T> outerPromise)
maybe?The text was updated successfully, but these errors were encountered: