Re: [webidl] DOMString
Hi Oliver. Oliver Hunt: Conceivably the language could be a relatively simple and broad statement along the lines of: Any type conversions needed for a language binding should occur before an API function is called, if a type conversion fails for any reason the call should be aborted However this doesn't address the issue of callbacks that throw exceptions, or returns incorrect types leading to an exception on type conversion, etc, etc I’ve added wording to cover this, but without using RFC 2119 language; the spec doesn’t define a conformance class for language bindings. http://dev.w3.org/2006/webapi/WebIDL/#callback-attribute-exceptions http://dev.w3.org/2006/webapi/WebIDL/#callback-operation-exceptions http://dev.w3.org/2006/webapi/WebIDL/#type-conversion-exceptions The ECMAScript binding as currently written should follow these guidelines already. I’ve yet to add a section in the Java binding on how “host objects” should deal with “user implemented objects”. -- Cameron McCormack ≝ http://mcc.id.au/
Re: [webidl] DOMString
Anne van Kesteren:
If something takes a DOMString as value is it clearly defined what
happens if the toString algorithm throws or returns a non-DOMString? I
haven't been able to find descriptions for that in the Web IDL
specification. E.g.
obj = { toString:function() { throw(haha) } }
obj2 = { toString:function() { return 1 } }
obj3 = { toString:function() { return obj } }
Oliver Hunt:
The [[ToString]] algorithm is defined in ECMAScript (Section 9.8, [1]),
the specified behaviour would result in [[ToString]] on obj2 producing
the string 1; [[ToString]] on obj3 will result in a TypeError, as
[[DefaultValue]] will produce a non-primitive type (Section 9.1, [1])
I would assume that the exception will be propagated to the runtime, but
it should be stated.
Added some text for this:
http://dev.w3.org/2006/webapi/WebIDL/#es-handling-exceptions
Let me know if you think it’s insufficient.
Thanks,
Cameron
--
Cameron McCormack ≝ http://mcc.id.au/
Re: [webidl] DOMString
On Tue, Apr 21, 2009 at 8:30 PM, Cameron McCormack c...@mcc.id.au wrote: Cameron McCormack: Seems reasonable to state that. I’ve added a note to do that when I get some time to allocate to editing Web IDL again. Oliver Hunt: I actually thought about this some more, and realised i'm not entirely sure this should be part of webidl as it seems a little too language specific. Eg. WebKit also provides an objective-c interface to the DOM to application developers, allowing them to interact with a webpage (or other content) through the DOM directly from their application code. It’s only the ECMAScript language binding that uses the ES ToString etc. algorithms, so I think it would be fine to define in the ES language binding section that exceptions thrown when converting an IDL value to an ECMAScript value or vice versa will propagate to whatever invoked that conversion. We could certainly add similar language for the Java language binding section too, though I think there’s less scope for those conversions to throw exceptions (maybe ones like OutOfMemoryException). I'm not sure, but I think you might have meant OutOfMemoryError. All Errors are unchecked in Java. Java also has unchecked exceptions, though unlike Errors there are exceptions that are checked at compile-time (checked exceptions). All of the dom exceptions are runtime exceptions. (TYPE_MISMATCH_ERR, for example) exception propagation behaviour is going to be somewhat language specific, since some language bindings may not even have exceptions as part of the language, so I think that means that it should be defined separately for each language. Which languages don't throw unchecked exceptions? Until (unless) somebody writes up a Web IDL language binding for Objective-C, the best you can hope for is for Obj-C implementations to do something “sensible”. Like throw a runtime error? Garrett
Re: [webidl] DOMString
Hi Garrett. Cameron McCormack: We could certainly add similar language for the Java language binding section too, though I think there’s less scope for those conversions to throw exceptions (maybe ones like OutOfMemoryException). Garrett Smith: I'm not sure, but I think you might have meant OutOfMemoryError. Yep that’s what I meant. All Errors are unchecked in Java. Indeed. Java also has unchecked exceptions, though unlike Errors there are exceptions that are checked at compile-time (checked exceptions). All of the dom exceptions are runtime exceptions. (TYPE_MISMATCH_ERR, for example) Yeah, I’ve made those exceptions extend RuntimeException. Which languages don't throw unchecked exceptions? C, for example, which doesn’t have exceptions at all. Until (unless) somebody writes up a Web IDL language binding for Objective-C, the best you can hope for is for Obj-C implementations to do something “sensible”. Like throw a runtime error? Perhaps; I don’t know Obj-C so I couldn’t say. -- Cameron McCormack ≝ http://mcc.id.au/
Re: [webidl] DOMString
Conceivably the language could be a relatively simple and broad statement along the lines of: Any type conversions needed for a language binding should occur before an API function is called, if a type conversion fails for any reason the call should be aborted However this doesn't address the issue of callbacks that throw exceptions, or returns incorrect types leading to an exception on type conversion, etc, etc --Oliver On Apr 21, 2009, at 11:46 PM, Cameron McCormack wrote: Hi Garrett. Cameron McCormack: We could certainly add similar language for the Java language binding section too, though I think there’s less scope for those conversions to throw exceptions (maybe ones like OutOfMemoryException). Garrett Smith: I'm not sure, but I think you might have meant OutOfMemoryError. Yep that’s what I meant. All Errors are unchecked in Java. Indeed. Java also has unchecked exceptions, though unlike Errors there are exceptions that are checked at compile-time (checked exceptions). All of the dom exceptions are runtime exceptions. (TYPE_MISMATCH_ERR, for example) Yeah, I’ve made those exceptions extend RuntimeException. Which languages don't throw unchecked exceptions? C, for example, which doesn’t have exceptions at all. Until (unless) somebody writes up a Web IDL language binding for Objective-C, the best you can hope for is for Obj-C implementations to do something “sensible”. Like throw a runtime error? Perhaps; I don’t know Obj-C so I couldn’t say. -- Cameron McCormack ≝ http://mcc.id.au/
[webidl] DOMString
If something takes a DOMString as value is it clearly defined what happens
if the toString algorithm throws or returns a non-DOMString? I haven't
been able to find descriptions for that in the Web IDL specification. E.g.
obj = { toString:function() { throw(haha) } }
obj2 = { toString:function() { return 1 } }
obj3 = { toString:function() { return obj } }
--
Anne van Kesteren
http://annevankesteren.nl/
Re: [webidl] DOMString
On Apr 21, 2009, at 1:38 AM, Anne van Kesteren wrote:
If something takes a DOMString as value is it clearly defined what
happens if the toString algorithm throws or returns a non-DOMString?
I haven't been able to find descriptions for that in the Web IDL
specification. E.g.
obj = { toString:function() { throw(haha) } }
obj2 = { toString:function() { return 1 } }
obj3 = { toString:function() { return obj } }
The [[ToString]] algorithm is defined in ECMAScript (Section 9.8,
[1]), the specified behaviour would result in [[ToString]] on obj2
producing the string 1; [[ToString]] on obj3 will result in a
TypeError, as [[DefaultValue]] will produce a non-primitive type
(Section 9.1, [1])
I would assume that the exception will be propagated to the runtime,
but it should be stated.
--Oliver
[1] ECMA262-5 RC
http://www.ecma-international.org/publications/files/drafts/tc39-2009-025.pdf
--
Anne van Kesteren
http://annevankesteren.nl/
Re: [webidl] DOMString
Anne van Kesteren: If something takes a DOMString as value is it clearly defined what happens if the toString algorithm throws or returns a non-DOMString? Oliver Hunt: I would assume that the exception will be propagated to the runtime, but it should be stated. Seems reasonable to state that. I’ve added a note to do that when I get some time to allocate to editing Web IDL again. Thanks, Cameron -- Cameron McCormack ≝ http://mcc.id.au/
Re: [webidl] DOMString
On Apr 21, 2009, at 6:08 PM, Cameron McCormack wrote: Anne van Kesteren: If something takes a DOMString as value is it clearly defined what happens if the toString algorithm throws or returns a non-DOMString? Oliver Hunt: I would assume that the exception will be propagated to the runtime, but it should be stated. Seems reasonable to state that. I’ve added a note to do that when I get some time to allocate to editing Web IDL again. I actually thought about this some more, and realised i'm not entirely sure this should be part of webidl as it seems a little too language specific. Eg. WebKit also provides an objective-c interface to the DOM to application developers, allowing them to interact with a webpage (or other content) through the DOM directly from their application code. Thanks, Cameron -- Cameron McCormack ≝ http://mcc.id.au/
Re: [webidl] DOMString
It’s only the ECMAScript language binding that uses the ES ToString etc. algorithms, so I think it would be fine to define in the ES language binding section that exceptions thrown when converting an IDL value to an ECMAScript value or vice versa will propagate to whatever invoked that conversion. Oh of course, completely forgot that there's actually a set of bindings sections :D Until (unless) somebody writes up a Web IDL language binding for Objective-C, the best you can hope for is for Obj-C implementations to do something “sensible”. Effectively this is what WebKit does to generate it's ES and Obj-C bindings. -- Cameron McCormack ≝ http://mcc.id.au/
