What we have here is a failure to communicate

bill — Fri, 14 Nov 2008 02:33:49 GMT

you can tell from the title there’s a Friday rant coming can’t you ? Well yeh, sometimes what should be a simple task of writing code becomes painstakingly slow. Take for example this one line of code:

  Dim doc = XDocument.Load("abc.xml")

Now if you like to write robust code, somewhere in your mind there should be that voice saying, “ah but what if the file is not there or can’t be opened or isn’t valid xml “…etc, etc. So the first thing you probably think of doing is look at what exceptions the method can throw, or so you’d hope.

Problem 1. VB doesn’t display the exception information from any xml documentation. Our first failure to communicate that then leads us on a great chase.

Problem 2. Who ever wrote the XDocument.Load method actually failed to provide the exception documentation. The Load method calls external methods such as XMLReader.Create and the exceptions from that are unchecked, allowed to bubble through. The documentation should indicate an include statement to say the XMLReader.Create exceptions bubble up. The author(s) of XDocument.Load failed to communicate the exceptions that could be thrown.

Problem 3. If you like to keep current and have installed the SilverLight 2.0 SDK, F1 help will take you to a SilverLight topic even if you are writing a Console application. That little voice in your head that first said “what if …” is now screaming. There’s a failure to communicate between Visual Studio and MSDN help.

Problem 4. Your only resolve is to do the lookup in msdn help yourself, only to find the documentation has no exception information because it relies on the xml documentation (see Problem 2). The failure to communicate cascades.

Problem 5. As a last ditch desperate measure you use Reflector and walk through the code. Thankfully in this case the code is reasonably simple. The problem now is how do you get that information back into your code, so as you handle the correct exceptions ? This isn’t Relector’s fault as such, as the same problem exists if you do find the exception information in Visual Studio’s object browser. This is a failure to interact, but it can result in you not handling exceptions or documenting which exceptions bubble up from your methods, causing your code to fail to communicate. (see Problem 2.)

If religious wars were still in fashion, we’d be saying “hey what about checked exceptions al la Java ?”. The more I am frustrated at how hard it is to write robust code because of these often cascading failures to communicate, the more I want to sign up with the holly sect for checked exceptions.

An alternative is to provide rich tooling and analysis. Some years ago, myself and Geoff Appleby with some help from Mark Miller wrote a plug-in for refactor that did a look up based on the code you selected. It would match the method calls with their xml documentation, refine and sort the list based on inheritance rules (most specific first), and let you choose which ones to add to your code. It really was simple once you got the method info, which is where refactor (or more accurately DXCore) came in. Unfortunately we hosted that project on the now defunct GotDotNet site :(

Such a tool helps break the cycle here, but such a tool also needs to be used by Microsoft (see Problem 2 above), and there needs to be analysis to ensure exceptions are either handled or the documentation says what exceptions can be thrown. Writing robust code needs to be easier: we cannot just ignore exceptions.

Does silverlight really make sense ?

bill — Sun, 23 Mar 2008 05:24:19 GMT

Earlier today I followed Soma's link to the updated Visual Studio Express pages. Soma gave emphasis that the "approach was to add Silverlight without making it look like we just dropped something new into our existing site without any thought". Hmmm, could have fooled me ;)

The first thing I noticed (other than having to allow the AgControl Class addon) was with the new site I have to wait for silverlight data to be downloaded. And that is slow. But why do I have to wait ? Seems all that is really being brought down is a series of about 10 slide shows. Sure to the naive they look pretty because the screen shots are on angles, but it's also incredibly useless. You can't even navigate through those slides. It's like it was designed to wow the bosses inside on the corporate network as they sit back and watch the slide show. As far as end user goes, it sucks. Why the hell should I have to wait for (and pay for the bandwidth used by) a useless bunch of slides ? What ever happened to *asynchronous* fetching of data ?

And the big problem for users is they don't know if they are able to get the same content without Silverlight. Was there any real gain to the user ? Or did it force the user to wait, and in fact make navigation more awkward (such as when you go forward and then go back, you have to sit and wait through the slide show again depending on which slide was relevant to you).

What scares me is that Soma is proud of this usage of SilverLight. I guess that means he must have just sat back and watched the slide-show over the corporate intranet :(

@ Head : Silverlight

What we have here is a failure to communicate

Does silverlight really make sense ?