Subj : Re: SpiderMonkey: JavaScript exceptions and native code To : Braden McDaniel From : Brendan Eich Date : Sun Aug 10 2003 11:41 pm Braden McDaniel wrote: >On Sun, 10 Aug 2003 22:11:32 -0700, Brendan Eich wrote: > > >>Braden McDaniel wrote: >> >>>an failure in any of the JS_* API functions result in a JavaScript >>>exception being thrown? What, in general, is the proper way to deal with >>>that in native code? Just return JS_TRUE ASAP? >>> >>> >>No, return JS_FALSE. A false return (or null, if the return value is of >>pointer type and null is available without overloading that return >>value) means error or exception. You can check whether an exception is >>pending on a given context with JS_IsExceptionPending. >> >>The JS_Compile*, JS_Evaluate*, JS_ExecuteScript, and JS_CallFunction* >>APIs will report uncaught exceptions if returning false or null to a >>caller using a context with no stack frames active. >> >> > >So returning JS_FALSE from a native method implementation only terminates >the script if no exception is pending? > Hmm, why does that follow from what I wrote in reply to what you wrote? Ah, I wrote "terminate" meaning "end normal execution". The ECMA spec uses slightly different language to-do with abrupt vs. normal completion. I should use the more precise jargon; sorry. Anyway, the idea is that returning false from a native function stops the calling script in its tracks. Whether the calling script can resume abnormally via try/catch/finally is a different question -- but it is not going to execute the next statement after the call within the same basic block. So normal completion has been terminated, and an abrupt completion due to an error-as-exception being thrown may be caught, or it may unwind all the way, resulting in an error report. /be .