{"id":105186,"date":"2021-05-05T07:00:00","date_gmt":"2021-05-05T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=105186"},"modified":"2021-05-05T06:53:32","modified_gmt":"2021-05-05T13:53:32","slug":"20210505-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20210505-00\/?p=105186","title":{"rendered":"Why is coroutine_handle::resume() potentially-throwing?"},"content":{"rendered":"

In our explorations of making co_await<\/code>able objects<\/a>, we had largely been ignoring the possibility of the coroutine handle throwing an exception upon resume<\/a>. But according to the language specification, the resume<\/code> method (and its equivalent, the operator()<\/code> overloaded function call operator) is potentially-throwing. Is this an oversight or an intentional decision?<\/p>\n

Well, the noop_coroutine<\/code>‘s coroutine handle does mark its resume()<\/code> method as noexcept<\/code>, so it’s not like the authors of the coroutine specification simply forgot about noexcept<\/code>. They consciously put it on the resumption of a noop_coroutine<\/code>, but omitted it from other coroutines.<\/p>\n

What’s more, if you look at libraries that operate on coroutines, all of them treat the resume<\/code> method as if it were noexcept<\/code>.<\/p>\n

What’s the deal?<\/p>\n

Gor Nishanov explained it to me.<\/p>\n

Allowing resume<\/code> to throw was introduced in P0664R6 section 25<\/a>, with this remark:<\/p>\n

\n

This resolution allows generator implementations to define unhandled_exception as follows:<\/p>\n

  void unhandled_exception() { throw; } \r\n<\/pre>\n
With this implementation, if a user of the generator pulls the next value, and during computation of the next value an exception will occur in the user authored body it will be propagate back to the user and the coroutine will be put into a final suspend state and ready to be destroyed when generator destructors is run.<\/p>\n<\/blockquote>\n
Yeah but what does that all mean?<\/p>\n
The scenario here is the use of coroutines as generators.<\/p>\n
If a generator encounters an exception, the normal mechanism would be for the exception to be captured in the coroutine’s unhandled_exception<\/code> method so that it can be re-thrown when the caller performs an await_resume<\/code>. But if the generator is synchronous (performs no co_await<\/code> operations), then it is more efficient to just let the exception propagate across the coroutine boundary directly to the caller.<\/p>\n
The coroutine implementation (specifically, the promise) can indicate that it wants the exception to propagate by rethrowing the exception in unhandled_exception<\/code>, rather than capturing it.<\/p>\n
But if you’re not in the case of a synchronous generator (and when dealing with coroutines as tasks, you won’t be), then resume<\/code> is indeed nonthrowing.<\/p>\n
Bonus reading<\/b>: Another reason for not marking resume()<\/code> as noexcept<\/code> is that resume()<\/code> requires that the coroutine be suspended. The presence of a precondition means that, according to  the Lakos Rule<\/a>, the function should not be marked noexcept<\/code>. This allows the implementation to choose to report the precondition violation in the form of an exception.<\/p>\n","protected":false},"excerpt":{"rendered":"
It enables a very specific usage scenario.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-105186","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
It enables a very specific usage scenario.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/105186","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=105186"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/105186\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=105186"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=105186"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=105186"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}