This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 16470 - Exception message contruction
Summary: Exception message contruction
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: WebIDL (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Cameron McCormack
QA Contact: public-webapps-bugzilla
Depends on:
Reported: 2012-03-21 19:22 UTC by Marcos Caceres
Modified: 2012-03-21 22:38 UTC (History)
2 users (show)

See Also:


Description Marcos Caceres 2012-03-21 19:22:18 UTC
I might have screwed something up, but implementing the algorithm can result in message becoming "undefined", from this line: 

Test case:
var test = new FooError() 

function(arg0) {
  //.... arg0 is undefined. 
  //If n > 0, then:
   if (arguments.length > 0) {

  //Let S be the result of calling ToString(arg0).
  var S = ECMAScript.ToString(arg0);
Maybe the spec should check that arg0 is not undefined? 

Question: can a default message be set somehow in through the IDL?
Comment 1 Marcos Caceres 2012-03-21 19:38:55 UTC
Also, I think the Exception JS binding section is confusing with regards to setting message (when no argument is missing). It should be a bit more clear that ECMAscript Error gives you message and type in the prototype.  

Generally, I've struggled a bit with the exception stuff... it is a bit all over the place. I have to bounce between many parts of the spec to find all the bits I need to put it together. It would be much easier if everything was brought together in one place with less critical bits missing from definitions. I guess once I'm done you will be able to see how I had to copy/paste parts of the spec into a kind of Frankenstein... I shouldn't have to do that when following algorithms (ECMAScript does this really nicely). 

code is here:

Search for "ExceptionFactory".
Comment 2 Cameron McCormack 2012-03-21 22:38:25 UTC
Do you mean that passing undefined to built-in error constructors will result in no message being set, while for Web IDL error constructors it will set the message to "undefined"?  If so, you're right, we should follow what the built-in ones do.

Default messages cannot be set in the IDL.

I've added a clarifying note that setting the message property shadows the one from Error.prototype.;r2=1.491;f=h