overhaul exception handling #307

Jotting down some notes from discussion with @gamburgm

RacketScript runtime throws exceptions in different ways right now:

• throw JS exceptions directly
  • e.g.,

    racketscript/racketscript-compiler/racketscript/compiler/runtime/core/struct.js

    Line 173 in c1f802a

    throw new Error(`TypeError: invalid field at position ${n}`);

  • everything using check.js (kernel fns) also directly raises JS (e.g., TypeError) exceptions

  • racketscript/racketscript-compiler/racketscript/compiler/runtime/core/check.js

    Line 2 in 71fdbaa

    throw exp.apply(this, args);

  • this is convenient sometimes but is more difficult to make the error msgs same as racket
• error.js api
  • e.g., as used by hash and other core runtime libs

  • racketscript/racketscript-compiler/racketscript/compiler/runtime/kernel.rkt

    Line 401 in 71fdbaa

    (throw (#js.Core.racketContractError "invalid number of arguments")))

  • allows more directly compilation, and simulating racket err msgs exactly, but is this extra abstraction worth it?
• continuation marks (maybe?)
  • maybe confuses things more since it uses JS Error objects for control flow

  • racketscript/racketscript-compiler/racketscript/compiler/runtime/core/marks.js

    Line 118 in 71fdbaa

    throw new Error("current frame doesn't match with old frame");

Ideally, RS would have one unified api for errors, and use it consistently everywhere.

One complicating factor is that different parts of Racket itself doesnt respect abstractions sometimes:

• sometimes the high level API is used, e.g., error or raise-arguments-error
• other times, low level constructs are used, e.g., raise <exn struct>

So any solution would need to be handle both scenarios above