This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: https://html.spec.whatwg.org/multipage/webappapis.html Multipage: https://html.spec.whatwg.org/multipage/#runtime-script-errors Complete: https://html.spec.whatwg.org/#runtime-script-errors Referrer: https://html.spec.whatwg.org/multipage/ Comment: Clearer spec for "message" in onerror "Let message be a user-agent-defined string describing the error in a helpful manner." I think this should have a more predictable format such that for any exception thrown by the author at least, the message should be testable with === in test cases. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3318 Posted from: 90.230.218.37 by simonp@opera.com User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.62 Safari/537.36 OPR/26.0.1656.20 (Edition beta)
Can't authors just get the actual object and use that? That's far better practice.
(In general I think we could do as you suggest, though. Can DOM define a spec hook for getting the standardised string out of an Error or DOMException object? Or should I define the pattern here?)
Simon, how would you deal with localizing the error message?
Don't localize the JS-exposed string.
If we actually want to follow that through, it seems that JavaScript should make these fixed first, no?
I agree with comment 1 in general and don't see a need for this.
(In reply to Anne from comment #5) > If we actually want to follow that through, it seems that JavaScript should > make these fixed first, no? Yeah sure. (In reply to Domenic Denicola from comment #6) > I agree with comment 1 in general and don't see a need for this. OK, let's drop this.