JavaScript:SpiderMonkey:LongTermPlans: Difference between revisions

talk about error reporting stuffs
(jschar/char16_t situation cleanup)
(talk about error reporting stuffs)
Line 14: Line 14:


...
...
== VM ==
=== Remove <code>JSContext</code> as a concept ===
Historically a <code>JSContext</code> included state necessary to run JS code.  These days, most such state is instead stored in <code>JSRuntime</code>, and some state is stored per-compartment or per-global object or per-zone.  If we can move all such information out of <code>JSContext</code>, we should be able to get rid of it entirely.  <code>JSRuntime</code> or global/compartment-centric methods would expose all the same information.
=== Add a warning mechanism distinct from the error-reporting mechanism ===
Reporting a warning right now requires creating an error type, an error message reporter, and other inanities.  Warnings should be reporting in a distinct manner from exceptions and shouldn't use the same overloaded mechanism.
=== Remove error reporting, replace it with exception-catching mechanisms ===
We currently have ''both'' error-reporting, and exception-throwing, error mechanisms.  Two is too many.  We need to come up with a coherent story for how to deal with all of this, that plays naturally to JS semantics.  That probably means that errors should be dealt with only in terms of exception objects.  And as far as extracting the information currently in a <code>JSErrorReport</code> goes, that should probably be exposed through a method that takes in a value/object and returns the right data if a usable Error object was passed, or some sort of plausible, partial substitute if not.


== JIT ==
== JIT ==
Confirmed users
446

edits