67645 - [RFE] Need column number in JS error handler

Status: VERIFIED DUPLICATE of bug 52120

(Core :: DOM: Core & HTML, enhancement)

Description

[bht237]

It would be logical being able to access _programmaticallly_ the information
that is available to every end user with a few mouse clicks.

Since Netscape 3, the column number of a script error has been availabe by means
of "...............^" in the error dialog box, and in MS IE directly as a number.

JavaScript is really easy-going as far as additional function parameters are
concerned, so we should be able to write:

function customErrorHandler(errorString,url,lineNumber,_columnNumber_){
    //error handling code
    return true;
}//End of function

- without any backwards compatibility problems.

The commercial background of this request is the need for a browser as a
dependable application platform for closed-loop process type of systems where
excellent error handling is a non-negociable requirement.

This is a critical requirement for mission-critical systems and not just a
nice-to have feature.

More background information:

1) One cannot force a programmer to NOT write multiple statements on a single
line simply because the language supports it and provides no means to prevent it.

2) Network bandwidth and cost constraints are strong logical forces towards
script compression where whole scripts with hundreds of statements are on a
single line. Please see view-source:www.msn.com as an example.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Actually, looks like a fix with this functionality was just attached to bug
67647.  hewitt, would this just be a dup?

Comment 2

[Joe Hewitt (gone)]

I'm marking this WORKSFORME because there has long been an API in mozilla for
programmatically accessing the error information that the reporter is asking
for.  See the interfaces nsIConsoleService and nsIScriptError.



  

Comment 3

[Phil Schwartau]

Marking Verified - 

Comment 4

[bht237]

nsIConsoleService and nsIScriptError: This doesn't look like JavaScript to me.
Or is there a bridge to JavaScript for this so I call it (Mozilla specific code)
in a window.onerror handler?
 

Comment 5

[Phil Schwartau]

Joe, any comment on [e-mail] 's question above? 

cc'ing jband in case he has any advice here - 

Comment 6

[John Bandhauer]

A few points:

- This is not a JS engine bug. window.onerror is a DOM feature and has nothing 
directly to do with the JS engine.

- I discovered that window.onerror is broken anyway and a known bug. I just sent 
off mail to try to shame the owner into fixing it. See bug 52120.

- The JS engine does not have column info on runtime errors - only on 
compile-time errors (generally syntax errors). A compile-time error would not be 
catchable in the same script (since it is not runnable when its own 
compilation fails) but ought to be catachable from a previously compiled script. 
I notice that both 4.x and mozilla do send the event for compile-time errors. 
Still, it seems to me that the vast majority of cases where you would want to 
catch an error with onerror would be runtime errors - e.g. object has no 
property with that name, etc. I think that programatically catching compile-time 
errors in an onerror handler is a pretty marginal activity.

Anyway, I'm reassigning to the DOM owner to let him resolve this bug as he 
chooses.

Comment 7

[bht237]

Thanks John for your valuable comments.

I basically agree, however John's comments have created a few more thoughts:

The nature of errors is usually such that very few pople can predict where and
when they occur.

Good examples are:

Microsoft's Internet Explorer 5 fires a frameset onLoad event exactly when the
transfer of frame documents is interrupted and the corresponding local error
pages are loaded into the frame(s).

Netscape Communicator 4 keeps "Transfer interrupted" documents in the cache,
which creates an unrecoverable error condition.

In both of the above cases, compile time errors do occur and catching them
has a very high value.

Being able to have column numbers here would certainy have benefits that
would raise the quality of the Mozila browser to a more competitive level.

I have my own personal example to back up the statement above:

I am using the Netscape script debugger applet jsDebug.
Apart from some nuisance factors, it is incredibly useful for me partly because
of an accident:
It does catch racing-condition-like runtime errors where I know that users
had them but I was never able to reproduce them normally with any of my computers.
And I am sure that when the debugger was written that the designers did not
plan for this feature. It is just plain coincidence!

From all that I conclude that every visible chance to utilise error handling
should be exploited to the fullest extent.

The lifetime of a browser is not that long, and with later generations
and competing products, other unforseen problems will be added.

Examples for this are the try{}catch{} statement and Mozilla's strict mode.
One cannot use these yet in the heterogenous environment that exists today.

IMHO, part of the key to Mozilla's success as a commercial application platform
is in the combination of the small components that make it more robust and
dependable than competing products.

Better standards compliance in rendering web pages is certainly a huge goal
but please consider the developers who have to work through the weekends because
of hard-to-find program errors.

Comment 8

[Keyser Sose]

Going to make this a [RFE] I believe its a very good idea for us developers.
Marking NEW.  Feel free to banter about until someone reassigns to
[e-mail] :)

Comment 9

[Johnny Stenback (:jst)]

*** This bug has been marked as a duplicate of 52120 ***

Comment 10

[Phil Schwartau]

Verified Duplicate -