v12-alpha: The raise call started recreating exn, which breaks try/catch

[DZakh]

Since it accepts the exn type, I expect it to simply generate throw exn instead of recreating an exception instance, which might break on exn having a Js error.

v11: https://rescript-lang.org/try?version=v11.1.3&code=C4JwngBA3gUBECkDOA6AogDwHYpAQwEskBTNEEAexAAoAiAMwotoEoYBfCAYz2C4AtoMAD4Ri2CAF4AfBHxFi1cVjbsYMcV2IAHYAQpYIAFWJJg60JFjx5JaibOruvAUNHKps24uWqgA

v12: https://rescript-lang.org/try?version=v12.0.0-alpha.1&code=C4JwngBA3gUBECkDOA6AogDwHYpAQwEskBTNEEAexAAoAiAMwotoEoYBfCAYz2C4AtoMAD4Ri2CAF4AfBHxFi1cVjbsYMcV2IAHYAQpYIAFWJJg60JFjx5JaibOruvAUNHKps24uWqgA

[aspeddro]

I think we can change Js.Exn.raiseError function to:

let raiseError = str => raise(Failure(str))

Playground

[aspeddro]

There is no idiomatic way to throw other errors like EvalError. In fact, there never was.

[aspeddro]

Something we can support is exception name as error name.

exception EvalError(string)


raise(EvalError("foo"))

compile to:

throw new EvalError("foo", {
        cause: {
          RE_EXN_ID: "EvalError",
          _1: "foo"
        }
      });

[DZakh]

That's not the point. How we throw an error doesn't matter since it might come from an unexpected runtime exception. It still shouldn't break in the case. If the code is in Js_dump, I can probably fix it myself.

[DZakh]

This is how I see the solution for the issue #6933

[DZakh]

I can implement it myself during the week