Throwing Exceptions

[SrinivasGourarum]

Could you please explain how to throw exception to the JS from C# code?

The js file goes something like this: try { Button btn = new Button();//js object which refers to the ui Button control btn.text = undefined;//this is expected to throw an exception } catch(e) {

}

Inside the property callback for setter, I have tried the following:

public JavaScriptValue onSetPropertyNotificationFromChakra(JavaScriptValue callee, bool isConstructCall, [MarshalAs(UnmanagedType.LPArray, SizeParamIndex = 3)] JavaScriptValue[] arguments, ushort argumentCount, IntPtr callbackData) { try { //call to c# which throws the exception } catch(Exception ex) { //created an error object using the message from the exception return JavaScriptValue.CreateError( ex.message);
} }

I have tried returning the error object, and also throwing JavaScriptException but unable to hit the catch block in the JS code.

[liminzhu]

After creating your error object, you can use JsSetException(errorObject) to throw.

[SrinivasGourarum]

Got it. Thank you.

[SrinivasGourarum]

I have a few more queries:

1. The setter callback is not expected to return any value since we are only setting a value. But the native fuction is expecting to return a value. Should we return undefined value or does it not matter?
2. Like wise, when there is an exception in the getter callback, should we return an undefined value?
3. When there is an exception while executing a function object by calling "callFunction", the exception has the following key value pairs:

1.message : string type 2.description:string type 3.number : double 4.stack: string

The value for "number" key is coming as "-2146823279" which appears to be wrong. The stack has all the right information with regards to line no, type of the error and the file in which the exception occurred. What does the value for "number" signify? Should we extract the information for the line no. and file name from the stack string or is there any other way?

[liminzhu]

The number is actually HRESULT so it may seem a bit off as a number. You can extract the debugging information that way but the Visual Studio script debugger should be able to catch exception if unhandled.

[SrinivasGourarum]

Thanks.