{"action":"opened","issue":{"url":"https://api.github.com/repos/executors/futures/issues/7","repository_url":"https://api.github.com/repos/executors/futures","labels_url":"https://api.github.com/repos/executors/futures/issues/7/labels{/name}","comments_url":"https://api.github.com/repos/executors/futures/issues/7/comments","events_url":"https://api.github.com/repos/executors/futures/issues/7/events","html_url":"https://github.com/executors/futures/issues/7","id":307400343,"number":7,"title":"Error handling","user":{"login":"LeeHowes","id":4451678,"avatar_url":"https://avatars1.githubusercontent.com/u/4451678?v=4","gravatar_id":"","url":"https://api.github.com/users/LeeHowes","html_url":"https://github.com/LeeHowes","followers_url":"https://api.github.com/users/LeeHowes/followers","following_url":"https://api.github.com/users/LeeHowes/following{/other_user}","gists_url":"https://api.github.com/users/LeeHowes/gists{/gist_id}","starred_url":"https://api.github.com/users/LeeHowes/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/LeeHowes/subscriptions","organizations_url":"https://api.github.com/users/LeeHowes/orgs","repos_url":"https://api.github.com/users/LeeHowes/repos","events_url":"https://api.github.com/users/LeeHowes/events{/privacy}","received_events_url":"https://api.github.com/users/LeeHowes/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2018-03-21T20:10:26Z","updated_at":"2018-03-21T20:10:26Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"In Jacksonville P0904R0 and P0701R2 both talked about error handling with continuations.\r\n\r\nAt Facebook we strongly favour an expected-style error handling mechanism, as a primary means.\r\nBased on feedback during the meeting, however, it is clear that a significant portion of people in the room want the simplest, default, means of chaining to be value-based, with error bypass.\r\n\r\nI would then propose the following:\r\n  * StandardFuture<T>::then accepts a continuation taking T&&, and returning T, expected<T, exception_ptr> or StandardSemiFuture<T> (this last point because the executor on the returned future does not matter because it is unpacked into the chain).\r\n  * StandardFuture<T>::thenExpected accepts a continuation taking expected<T, exception_ptr>&& and returning as above.\r\n  * StandardFuture<T>::thenError accepts an exception_ptr.\r\n\r\nthen can be defined as if:\r\n```\r\nStandardFuture<T>::then(F&& func) {\r\n return thenExpected([func = std::move(func)](expected<T, exception_ptr>&& e) {\r\n    if(e.hasValue()) {\r\n      return func(e.value());\r\n    } else {\r\n      throw e.exception();\r\n    }\r\n  });\r\n}\r\n```\r\n\r\nand thenError as:\r\n```\r\nStandardFuture<T>::thenError(F&& func) {\r\n return thenExpected([func = std::move(func)](expected<T, exception_ptr>&& e) {\r\n    if(e.hasValue()) {\r\n      return std::move(e);\r\n    } else {\r\n      return func(e.exception());\r\n    }\r\n  });\r\n}\r\n\r\n```\r\n\r\nOr similar. The names should be explicit to allow:\r\n```\r\nf.then([](auto&& p) {\r\n});\r\n```\r\n\r\nTo work without overload resolution issues."}}
{"actor":{"display_login":"LeeHowes"}}