|
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.
|