A Technical Debtor

VS Live San Francisco

2009-01-06T16:12:20-07:00:00

I've got the paperwork now, so I guess this is official.

I submitted a talk on writing concurrent applications for VS Live in San Francisco in February. I'll be speaking on Thursday Feb 26th -- if you happen to be making the conference, look me up! I'm looking forward to this; there's lots of great content being presented, including a full day post-con on Azure.

Using Exception Handling to Retry an Operation

2008-12-18T09:37:15-07:00:00

I got the following question via e-mail:

I want to catch timeout errors when I execute a script. Catching the error is easy, but I then want to retry 3 times. In VB6 I could just resume a command when I caught the error. How can I do this with vb 2008 using try..catch?

This is a case where two different techniques come into play. The first is using a number of Catch statements to allow you to catch specific types of exceptions. The second is to make essentially a recursive call to the function, with a counter to ensure that you don't end up in an infinite loop.

  1: Module Module1
  2:     Sub Main()
  3:         Foo()
  4:         Console.ReadLine()
  5:         Foo()
  6:         Console.ReadLine()
  7:     End Sub
  8: 
  9:     Private tryCounter As Integer = 0
 10:     Private maxAttempts As Integer = 3
 11:     Private Sub Foo()
 12:         Try
 13:             If tryCounter = maxAttempts Then tryCounter = 0
 14:             tryCounter += 1
 15:             FooWithTimeout()
 16:         Catch toex As TimeoutException
 17:             If tryCounter = maxAttempts Then
 18:                 Console.WriteLine("Too many failures.")
 19:             Else
 20:                 Foo()
 21:             End If
 22:         Catch ex As Exception
 23:             Throw
 24:         End Try
 25:     End Sub
 26: 
 27:     Private Sub FooWithTimeout()
 28:         Console.WriteLine("Attempt " & tryCounter)
 29:         Throw New TimeoutException
 30:     End Sub
 31: End Module

I've called Foo() twice from Main() simply to show that the function resets the attempt counter properly.

VB Dev Center Article Published

2008-12-17T13:59:06-07:00:00

The work I did on benchmarking DataTable performance (or lack thereof *cough cough*) has been published in an article on the MSDN VB Dev Center.

For those of you wondering about the results I mentioned a few months ago, they're included there. I've also included some work on benchmarking LINQ select queries and aggregation in comparison to the DataTable equivalents.

Many thanks to Beth Massi for helping get this published.

How to keep VS2010 CTP working past 1/1/2009

2008-12-10T08:34:18-07:00:00

For those of you playing with the VS2010 CTP, you've probably noticed that it's going to stop working around New Years. Jeff Beehler just posted this blog entry on how to extend the life of your (new) VS2010 VPC beyond that time.

Accidental Perplexity

2008-12-09T14:40:54-07:00:00

I was discussing accidental complexity with some co-workers after reading Dave Bouwman's recent post.

One of them coined the phrase "accidental perplexity," which we quickly defined as "when you look at a code base and can't figure out what on earth the developer was thinking." This is especially bad when the core reason for the perplexity is in the architecture.

Try/Catch Performance

2008-12-01T17:06:36-07:00:00

I'm really not obsessed with performance -- honest!

However, when a co-worker asked me today exception handling was an acceptable way of coding defensively, my reaction was rather predictable. Exceptions are pure evil, and should be... well, exceptional.

Yes, you guessed it. The next question was "How bad is try/catch really?"

The short answer is that is involves minimal overhead... unless an exception is thrown. In that case, the .NET exception handling mechanism does a few nice things, like providing the stack trace as part of the exception. Great for debugging... lousy for performance. Of course, if exceptions are treated as being exceptional -- that is, they're only raised when something you haven't predicted occurs -- then you really shouldn't care about performance. Since your application is most likely left in an unknown or unstable state after an exception, the odds are you're going to reset a substantial part of your application, if not shut it down entirely.

As a rule, you can predict that users will provide data that is, to put it politely, suspect. This isn't a reflection on the users; if anything, it's more a comment on the tendency of developers to know how their own code works, and to continually feed it good data. But, both for this reason, and for security reasons, the ASP.NET mantra of "never trust any input" applies in pretty much any application. Code defensively against user input, so that you don't have to rely on try/catch blocks to deal with exceptions.

How significant is the overhead of catching an exception? Here's the code for a console application to illustrate:

  1: Module Module1
  2:     Sub Main()
  3:         TestNaive(1)
  4:         TestDefensive(1)
  5:         TestWithTryCatch(1)
  6:         TestWithException(1)
  7: 
  8:         Dim maxCount As Integer = 1000000
  9: 
 10:         Console.WriteLine("Naive: " & TestNaive(maxCount) & " ticks")
 11:         Console.WriteLine("Defensive coding, no try/catch: " & TestDefensive(maxCount) & " ticks")
 12:         Console.WriteLine("Naive with try/catch: " & TestWithTryCatch(maxCount) & " ticks")
 13:         Console.WriteLine("Exception: " & TestWithException(maxCount) & " ticks")
 14:         Console.ReadLine()
 15:     End Sub
 16: 
 17:     Private Function TestNaive(ByVal iterationCount As Integer) As Double
 18:         Dim sw As New Stopwatch
 19:         sw.Start()
 20:         For i As Integer = 1 To iterationCount
 21:             Dim x As Double = i / (iterationCount - i + 1)
 22:         Next
 23:         sw.Stop()
 24: 
 25:         Return sw.ElapsedTicks / iterationCount
 26:     End Function
 27: 
 28:     Private Function TestDefensive(ByVal iterationCount As Integer) As Double
 29:         Dim sw As New Stopwatch
 30:         sw.Start()
 31:         For i As Integer = 1 To iterationCount
 32:             Dim y As Integer = (iterationCount - i + 1)
 33:             If Not y = 0 Then
 34:                 Dim x As Double = i / y
 35:             End If
 36:         Next
 37:         sw.Stop()
 38: 
 39:         Return sw.ElapsedTicks / iterationCount
 40:     End Function
 41: 
 42:     Private Function TestWithTryCatch(ByVal iterationCount As Integer) As Double
 43:         Dim sw As New Stopwatch
 44:         sw.Start()
 45:         For i As Integer = 1 To iterationCount
 46:             Try
 47:                 Dim x As Double = i / (iterationCount - i + 1)
 48:             Catch ex As Exception
 49: 
 50:             End Try
 51:         Next
 52:         sw.Stop()
 53: 
 54:         Return sw.ElapsedTicks / iterationCount
 55:     End Function
 56: 
 57:     Private Function TestWithException(ByVal iterationCount As Integer) As Double
 58:         Dim sw As New Stopwatch
 59:         sw.Start()
 60:         For i As Integer = 1 To iterationCount
 61:             Try
 62:                 Dim x As Double = i / 0
 63:             Catch ex As Exception
 64: 
 65:             End Try
 66:         Next
 67:         sw.Stop()
 68: 
 69:         Return sw.ElapsedTicks / iterationCount
 70:     End Function
 71: End Module

My results tend to vary a little bit, since the work done in each loop so trivial that it is susceptible to noise. The first three tests are generally pretty close to each other. The fourth test -- testing with an exception raised -- is always much longer. Generally it's somewhat more than 5x longer than the other tests.

What I find really interesting is that the inclusion of the try/catch block appears to make the naive implementation run faster. I don't have the .NET debugging symbols loaded on my machine, and dotTrace really didn't provide any insight. Anyone out there who has dug deeply into the CLR and can provide insight, it would be much appreciated.

However, the moral of the story is straight-forward. Treat exceptions as exceptional. Code defensively rather than catching exceptions wherever possible. No surprise there.

XamlFest: WPF/Silverlight Tools

2008-11-25T11:49:19-07:00:00

Both Snoop (WPF) and Silverlight Spy (Silverlight, obviously) allow you to connect to running processes and see what's going on inside them. Very powerful tools.

With Silverlight Spy, you can see the contents of any Silverlight app... and reflect against them. The temptation with Silverlight is to put more code in the stateful .NET client, but the consequence is that your code is essentially available to the world. This also applies to any keys, passwords, etc that may be stored within your code.

Time-sensitive encrypt keys from the server may be worth investigating as a means of protecting your secrets.

Really, it drives home the point that you need to be cognizant of where you store your secrets. In addition, you simply shouldn't trust anything coming from the client. Other strategies include routing all traffic through your secure server, rather than allowing direct access to web services. Treat your production Silverlight apps like any public-facing web site -- expect attacks, expect people to hammer at it and try to destroy it.

XamlFest: View-Model-ViewModel Pattern

2008-11-25T11:48:19-07:00:00

Some quick notes about one architectural pattern for WPF apps -- this is a modified version of MVC/MVP.

The Model

bottom layer of the pattern
no knowledge of the View (UI)
variables should be named in UI-agnostic terms ("available" vs "visible")
.NET class

The View

WPF/Silverlight representation of the UI
should have minimal code
connects to the ViewModel through the DataContext property
should be editable in either Blend or Visual Studio
XAML file

The ViewModel

represents the "glue" between the UI and the back end
presents data and interacts with code
responsible for property change notifications
exposes RoutedCommand and DelegateCommand commands
shouldn't contain references to specific UI elements

LiveWriter Code Formatting Plug-In

2008-11-18T17:14:46-07:00:00

Another thing that took me far too long to find today... there's a lot of links to Steve Dunn's tool, including the CodePlex version, which hasn't been updated since 2006. And, since it doesn't have an installer or the DLLs readily available, you'll waste a lot of time looking for that too.

You might consider trying this tool. Looks pretty good to me so far. And, yes, it supports a few languages. And line numbers. And highlighting.

Public Class ThisRocks
  Public Function URL As String
    Return "http://www.amergerzic.com/post/WLWSourceCodePlugin.aspx"
  End Function
End Class

  1: public ThisIsOkToo
  2: {
  3:   public string URL()
  4:   {
  5:     return "http://www.amergerzic.com/post/WLWSourceCodePlugin.aspx";
  6:   }
  7: }

A word of caution. There's a little silliness around seeing the formatted code properly in WLW. You'll end up getting used to switching to the HTML source and back... or just learning to trust the tool.

VB.NET Generics with Multiple Constraints

2008-11-18T17:05:48-07:00:00

I had a case today where I needed -- well, wanted -- to implement a generic class that was a little... unusual.

Essentially, I'm working on a queuing mechanism based on Joe Duffy's BlockingBoundedQueue(Of T). Mind you, unlike Joe's sample, mine is written in VB.NET. ;)

Taking it a bit further, I created a wrapper that specifies the number of producers and consumers of queued objects, as well as the queue capacity. Since I'm going to be turning this over to a bunch of developers to play with, I also wanted to be able to specify more tightly what types can be used for producers and consumers. This type specification also lets me raise events for diagnostics.

Now, this all sounds kind of easy, doesn't it? Well, it is... until you go looking for a good example of the syntax for generics with multiple constraints. I usually get good results from Google, and this took me far too long to find, so I thought I'd post it here.

The key is wrapping the multiple constraints for a single generic argument in the dreaded curly braces. A simple example is:

Public Class myClass(Of T As {New, myBaseClass})

A more complicated example could look something like this:

Public Class DataQueue(Of P As {New, Producer(Of T)}, C As {New, Consumer(Of T)}, T)