Error Object, Stack, and Parking Garages

This thread is a formalization of a bug-turned-discussion.
https://bugs.webkit.org/show_bug.cgi?id=55092

The initial problem is that window.onerror doesn't provide a stack
trace. But window.onerror is also inconsistent, has unmemorable and
not so useful params.

As a proposal, a global error handler with error stacks, to inspect
each function and the arguments passed to it.

As an example of how this would work, the program registers a global
error callback:

| global.addEventListener("scripterror", globalErrorHandler);
| function globalErrorHandler(err) {
|  alert([err.callstack[0], "\n", err.message].toString());
| }


When a script/DOM error occurs, the callback fires. The callback can
access the callstack, message, and error from the error event.

| // Cause an error to be thrown:
| document.createElement("12");

This example would result in an alert with text:

|  "function createElement() { /* [native code] */ }"
|  "DOMException: line 6 of inline script. '12' is an invalid tagName".

The example also assumes the following:
 * `useCapture` is not implementation-dependent
 * error events have a callstack property
 * Function.prototype.toString works as specified
 * DOM errors are real ECMAScript errors, with meaningful messages.
 * It always works (no swallowing chrome or DOM errors).
 * DOM numeric Error codes (which suck) are for legacy purposes.

The many problems of Errors deserve acknowledgement.

On the bright site, we're not as bad off as traffic. Drive into a
parking garage and notice how many pillars have paint rubbed onto
them. That is caused (generally) by a driver error. But damn, cement?!
ISTM a rubber layer would prevent a lot of bodywork.
-- 
Garrett

Received on Friday, 12 August 2011 04:12:41 UTC