[SERVER-46228] Add noexcept specifier to TaskExecutor::schedule functions Created: 18/Feb/20  Updated: 19/May/22  Resolved: 19/May/22

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major - P3
Reporter: Benjamin Caimano (Inactive) Assignee: Daniel Morilha (Inactive)
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Sprint: Service Arch 2022-05-30
Participants:

 Description   

The schedule*() family of functions always return StatusWith<Handle>. We should liberally apply the noexcept specifier and function try-catch to these functions so that we can trust the StatusWith and avoid try-catches around the function itself.



 Comments   
Comment by Daniel Morilha (Inactive) [ 19/May/22 ]

Already checked with the team and I failed to spark them into enough enthusiasm to pursue this. Closing, please reopen at some point if needed.

Comment by Daniel Morilha (Inactive) [ 19/May/22 ]

By reading through this ticket within the given time constrain it reminds me a lot of SERVER-58024. As long as my memory servers, the discussions held with George and Billy concluded that marking callback-based APIs noexpect would only result in early termination as the generic executor component will not be able to handle all current and possibly newer exceptions from the user-passed callbacks the API accepts. Therefore, I move to claim there is a lot of overlap between this ticket and SERVER-58024.

There, we chose to add a new catchingInvoke helper as a wrapper to callbacks which might throw, here's its description:

/**
 * Invokes `f()`, and returns true if it succeeds.
 * Otherwise, we log the exception with a `hint` string and handle the error.
 * The exception handling has two possibilities, controlled by the server parameter
 * `suppressNetworkInterfaceTransportLayerExceptions`.
 * The old behavior is to simply rethrow the exception, which will crash the process.
 * The new behavior is to invoke `eh(err)` and return false. This gives the caller a way
 * to provide a route to propagate the exception as a Status (perhaps filling a promise
 * with it) and carry on.
 */

While I agree with the author that StatusWith is the expected way to report errors and exceptions should never been handled, this sounds as an interesting transition step towards the ending goal of this ticket.

Comment by Lauren Lewis (Inactive) [ 21/Dec/21 ]

We haven’t heard back from you in at least 1 year, so I'm going to close this ticket. If this is still an issue for you, please provide additional information and we will reopen the ticket.

Generated at Thu Feb 08 05:10:52 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.