Skip to content

[browser] Mono/CLR deviate in implementation of exception handling during promise value marshalling #125587

@ArcadeMode

Description

@ArcadeMode

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:

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

Metadata

Metadata

Assignees

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions