Question

I’m having trouble adding proper exception handling to existing code that makes heavy use of Silverlight – JavaScript interoperability. In this case, my JavaScript can throw an exception that I want to handle meaningfully in Silverlight.

From Silverlight, I’m creating an instance of a JavaScript object, then later I’m calling a method on that object:

public class MyWrapper
{
    dynamic _myJSObject;

    public MyWrapper()
    {
        _myJSObject = HtmlPage.Window.CreateInstance("MyJSObject");
    }

    public int MyMethod()
    {
        try
        {
            int result = (int)_myJSObject.MyMethod();
        }
        catch (Exception ex)
        {
            // I want to add meaningful exception handling here
        }      
    }
}

Whenever MyJSObject.MyMethod throws an exception, there are two problems:

• The browser shows a message that an exception has occurred.
• Information about the exception is not passed to my managed code. Instead I get a RuntimeBinderException which just says “Cannot invoke a non-delegate type” and contains no other information whatsoever. This does not seem to match what is described here; I’d expect an InvalidOperationException.

I’ve tried avoiding to cast the returned value of the method:

object tmp= _myJSObject.MyMethod();

This makes no difference. Changing the type of exception thrown on the JavaScript side has no effect either.

MyJSObject.prototype.MyMethod = function ()
                                {
                                    throw "Hello Silverlight!";
                                }

The only solution I can think of right now is abusing the function’s return value to pass information about the exception, but that will make my code a whole lot uglier… so:

Why is the behavior I’m seeing different from what is described in documentation? Does it have to do with my use of dynamic somehow? How can I properly handle exceptions that occur in JavaScript in my managed code?

Answer 1

After quite a bit of experimentation, I concluded that there is no way to directly handle the JavaScript exception from Silverlight. In order to be able to process the exception, the JavaScript code needs to be changed slightly.

Instead of throwing the error, I return it:

function MyMethod()
{
    try
    {
        // Possible exception here
    }
    catch (ex)
    {
        return new Error(ex);
    }
}

Then on the Silverlight side, I use a wrapper around ScriptObject to turn the return value into an exception again. The key here is the TryInvokeMember method:

public class ScriptObjectWrapper : DynamicObject
{
    private ScriptObject _scriptObject;

    public ScriptObjectWrapper(ScriptObject scriptObject)
    {
        _scriptObject = scriptObject;
    }

    public override bool TryInvokeMember(InvokeMemberBinder binder, object[] args, out object result)
    {
        result = _scriptObject.Invoke(binder.Name, args);

        ScriptObject s = result as ScriptObject;
        if (s != null)
        {
            // The JavaScript Error object defines name and message properties.
            string name = s.GetProperty("name") as string;
            string message = s.GetProperty("message") as string;
            if (name != null && message != null && name.EndsWith("Error"))
            {
                // Customize this to throw a more specific exception type
                // that also exposed the name property.
                throw new Exception(message);
            }
        }

        return true;
    }

    public override bool TrySetMember(SetMemberBinder binder, object value)
    {
        try
        {
            _scriptObject.SetProperty(binder.Name, value);
            return true;
        }
        catch
        {
            return false;
        }
    }

    public override bool TryGetMember(GetMemberBinder binder, out object result)
    {
        try
        {
            result = _scriptObject.GetProperty(binder.Name);
            return true;
        }
        catch
        {
            result = null;
            return false;
        }
    }

}

Potentially you could improve this wrapper so it actually injects the JavaScript try-catch mechanism transparently, however in my case I had direct control over the JavaScript source code, so there was no need to do this.

Instead of using the built in JavaScript Error object, it’s possible to use your custom objects, as long as the name property ends with Error.

To use the wrapper, the original code would change to:

public MyWrapper()
{
    _myJSObject = new ScriptObjectWrapper(
                  HtmlPage.Window.CreateInstance("MyJSObject"));
}