The beauty of dynamic languages in Silverlight is you don't need an IDE; just work in a text-editor, save, and refresh the browser. Got errors in your code? No problem, a syntax error or exception will show up in your browser.
This functionality is enabled in the HTML that hosts Silverlight, so you can take a application and host it with debug-ability or not. Given HTML that looks like this: <object data="data:application/x-silverlight," type="application/x-silverlight-2-b1" width="800" height="600"> <param name="source" value="app.xap" /> <param name="initParams" value="debug=true, reportErrors=errorLocation" /> </object>The param "initParams" takes a comma-separated list of key=value pairs, which end up as a dictionary on Application.initParams. You can put arbitrary settings here, and read them into your application. Dynamic languages look for a couple of these options (below) to configure your application. If the option is not there, it's given a default value (in bold). Note: this is what these options "should" do; there are bugs and those are enumerated further down.
Error handling "initParams" options
- debug = true|false
- Runs your code as debug-able; stack traces will be shown if an error occurs. Also, this lets you attach the browser to a debugger and step through the running program.
- When omitted/set to false, all errors will be silent (for deployment purposes
- reportErrors = [HTML element ID]
- In the event of an error, the error window (shown in the screen shot above) will be written into the innerHTML property of the HTML element with an ID attribute matching the value of this field.
- If there is no matching ID, a HTML element is created with that ID, and the error window inserted
- If this field is omitted, no errors will be shown
- You can define the "onerror" param, which will let you handle any error with JavaScript (the index.html templates do this, if you want sample code)
- This just causes HTML to be generated in the HTML element; the styling of the error window is defined in a separate error.css file that must be included in the page.
- exceptionDetail = true|false
- If set to true, this will also show the entire managed stack trace in the error window rather than just the dynamic stack trace. This is useful when debugging C#/Visual Basic when called from a dynamic language.
What doesn't work in Silverlight 2 Beta 1?
- debug seems to have no effect on the stack-trace in Python and JScript.
- exceptionDetail only has an effect on Ruby code; Python and JScript always show a dynamic stack trace (Note: this is fixed in Silverlight 2 Beta 2)
Let me hear what you think!
Enabling this type of functionality is not the most obvious thing in the world, and may not be the best way either. I'm mostly interested in what you think about this:
- Is the behavior of each option intuitive, or did you think they did something else?
- I sometimes get confused with "reportErrors", since I think it's a boolean flag. I'd think changing the name to "errorReportId" would make more sense. Thoughts?
- Should we have a separate "error window" for debug=true|false, rather than just failing silently?
- Do you like having the separate error.css so you can have it for customization, or would you rather the CSS is generated in-line with the HTML when an error occurs?
- Having different error.css for development/deployment could be useful?
- Keep in mind in-line CSS will make it harder to customize the look of the error window.
- Anything else?