It stood out to me that the clr and mono implementations differ in their implementation of 'complete task wrapper' (part of the marshalling of values in Promise -> Task).
The mono implementation exits the runtime on exception in this process and clr does not.
clr:
|
} catch (ex) { |
|
// there is no point to propagate the exception into the unhandled promise rejection |
|
} |
mono:
|
} catch (ex) { |
|
try { |
|
loaderHelpers.mono_exit(1, ex); |
|
} catch (ex2) { |
|
// there is no point to propagate the exception into the unhandled promise rejection |
|
} |
|
} |
Judging by some quick experimentation, my guess is that the clr implementation will swallow errors in the marshalling code (thats what mono does if the catch block is emptied).
Like how formerly type assertions would throw, these would be swallowed (reversing e.g. #123523 would result in that behavior)
I want to propose these implementations be aligned. I see 2 possible approaches:
- This exception path should not be hit, instead exceptions are propagated through the task being marshalled. If this is the case, we should be able to remove the try catch altogether
- This exception path must be guarded with runtime exit. If this is the case, the clr implementation should also invoke runtime exit as the mono implementation currently does.
Would like to discuss before moving in either direction.
It stood out to me that the clr and mono implementations differ in their implementation of 'complete task wrapper' (part of the marshalling of values in Promise -> Task).
The mono implementation exits the runtime on exception in this process and clr does not.
clr:
runtime/src/native/libs/System.Runtime.InteropServices.JavaScript.Native/interop/marshaled-types.ts
Lines 256 to 258 in c38f37a
mono:
runtime/src/mono/browser/runtime/cancelable-promise.ts
Lines 179 to 185 in c38f37a
Judging by some quick experimentation, my guess is that the clr implementation will swallow errors in the marshalling code (thats what mono does if the catch block is emptied).
Like how formerly type assertions would throw, these would be swallowed (reversing e.g. #123523 would result in that behavior)
I want to propose these implementations be aligned. I see 2 possible approaches:
Would like to discuss before moving in either direction.