This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The spec currently gives guidance on how specs can use DOMError: "A specification could say that an error attribute must return a "SyntaxError" DOMError." It would be nice if the spec also gave guidance on how to use DOMError with a Future.
I guess that, for things that return futures, you just reject the future with the Error object as the reason.
(In reply to comment #1) > I guess that, for things that return futures, you just reject the future > with the Error object as the reason. Yes, of course. But I guess what I am looking for is if we need to use any special wording, link to a concept (reject, in this case), or invoke some algorithm/method in the DOM spec. The sysapps WG is about to transition about 5 specs to use futures, so the Editors are looking for ways to phrase things correctly and link to the right bits in the spec. Like with "fire an event", the spec gives guidance on how to write and link to the correct parts of the DOM spec: "If the event needs its bubbles or cancelable attribute initialized, one could write "fire an event named submit with its cancelable attribute initialized to true"." What we are looking for is equivalent to the above "one could write ... blah" for using futures. Futures is new so we are still a bit timid about how to wire them up in a spec that needs to use them. Hope that makes sense (just trying to avoid getting yelled at: "you guys are doing it all wrong!!!").
Don't use DOMError, basically. Still need to sort out the exact story for DOMException.
Actually, I'm not sure I agree with Comment 3. Why not use DOMError with the reject path of a Promise? It allows implementations to encapsulate meaningful errors, so that within the reject path, you can take action. If the counsel is to throw instead with DOMException, then that creates more try-catch style code, which, alongside Promises, is a bit of a pain. So this brings me back to my first question: why not use DOMError?
The problem is that DOMError doesn't inherit from Error, and should die a painful death from a thousand burning suns. Reject your promises with things that inherit from Error.
We should simply use DOMException rather than DOMError. And ideally clean up DOMException in various ways.
Wait, use DOMException, as in, throw (re: Comment 6), or use DOMException in some other way? And, is it too late (as in, too much legacy usage of DOMError) to hook it up to Error now?
No, use DOMException as in reject the Promise using a DOMException.
We could change DOMError to inherit Error. However DOMError is just a duplication of DOMException, so I'd rather simply deprecated DOMError and use DOMException everywhere.
OK, for some reason, I wasn't sure we could use DOMException outside the context of try catch code, but I suppose this would make more sense.
I think the plan should be to make DOMExceptions be some built in thing to Web IDL, and then allow referring to Error, TypeError, DOMException, etc. as types in Web IDL, which mean references to those kinds of objects. Then we can have FileReader.error be of type Error.
(In reply to Cameron McCormack from comment #11) > I think the plan should be to make DOMExceptions be some built in thing to > Web IDL, and then allow referring to Error, TypeError, DOMException, etc. as > types in Web IDL, which mean references to those kinds of objects. Then we > can have FileReader.error be of type Error. Am I right in thinking that most of the plumbing needed here hasn't been layed down in WebIDL? If so, when can we expect it?
I think this is mostly done now in IDL, with DOMException integrated.
I think this is fixed, as DOMError is dead and DOMException is an exception which is what you are expected to use with promises. Let me know if you disagree.