Handling Silverlight onerror callback

Question

The silverlight object tag accept an 'onerror' parameter which calls back to a piece og javascript of your choice. The default implementation the is generated by the Visual Studio template assembles a descriptive message and throw it as an Error (which lets e.g. IE display the little warning triangle).

It seems to me that each time this callback is fired our silverlight instance is dead and you need to refresh the page. Is this a reasonable deduction?

Another issue is how to best handle this callback. Showing the little warning icon is somewhat developer-centric and it doesn't allow us (the developers) to discover what is actually failing in production when it is run on a customer machine. What are people doing with this? A couple of our own (more or less concrete) ideas are:

• Send the error message back to the server via some exposed endpoint

• Remove hide the silverlight object, show a nicer and more descriptive message to the user and a 'refresh' link to start up the silverlight page again (we run a full-sized silverlight application so if the silverlight object isn't working, the customer might as well reload anyway)

• Somehow reload the object tag automatically to avoid having the customer perform any actions to get going again (perhaps combined with some notice to the customer that the 'system' restarted)

Ideas, thoughts, best practices, anti-patterns? What are you guys doing (except ensuring that the silverlight app never fails, but that's another discussion)?

Answer 1

I like a nice error reporting in the form of a "form" using SilverlightFX grab the source http://github.com/NikhilK/silverlightfx/tree/master , check it out very cool framework otherwise basically would be just a summary of the error, the ability to send it via upload that emails to support and an "oops we goofed" title :) I handle all unhandled expetions in this way, there is also a nice article on handling the errors by type using a dictionary http://www.netfxharmonics.com/2009/04/Exception-Handlers-for-Silverlight-20 also a fav of mine . Hope this helps

Answer 2

I recommend you change how you're instantiating the Silverlight control. Instead of using the object tag, you can call Silverlight.CreateObjectEx() in the Silverlight.js file. This is probably a little more natural for your scenario. If it fails, you can call it again which is simpler than trying to reload object tags. Ex:

Silverlight.createObjectEx(
     {
         source: '/../VideoPlayer.xap',
         parentElement: document.getElementById('movieplayerDiv'),
         id: 'VideoPlayer',
         properties: {
             width: '100%',
             height: '100%',
             background: '#FFd9e3d7',
             inplaceInstallPrompt: false,
             isWindowless: 'false',
             version: '2.0'
         },
         events: {
             onError: onSLError,
             onLoad: onSLLoad
         },

         initParams: "...",
         context: null
     });



    function onSLLoad(sender, args) {

    }

    function onSLError(sender, args) {
        //                alert('error');
    }

Other thoughts:

• If your javascript error handler fires, the instantiation has failed. Silverlight will not suddenly come back to life by itself. Instead, call CreateObjectEx to give it another shot ;)

• There are 2 kinds of terminal errors in Silverlight. 1) Managed errors (hit the managed Application_UnhandledException method). Note that some errors may not even get to this point. If the managed infrastructure can't be loaded for some reason (out of memory error maybe...), you won't get this kind of error. Still, if you can get it, you can use a web service (or the CLOG project) to communicate it back to the server. 2) Javascript errors. These are what you're getting right now. I recommend bouncing these back to your server with JQuery (or Javascript library of preference). Something like:

      $.post(this.href, { func: "countVote" },
  

  function(data) {...} How you handle this on the server, of course, is dependent on what your server stack looks like. It's super easy in MVC, btw.