Monthly Archives: November 2003

When to use “When”

I’m finally sorting through the stuff I came home from the PDC with, and I found a note that I jotted down pertaining to the When clause in VB.NET. While I was manning the booth, a reader named Matt Ryan started chatting with me about the blog. He mentioned that he’d read about the When clause in exception handling and noticed that every time it was discussed, the person talking about it would say “well, it’s cool, but I don’t know what you’d use it for.” He then proceeded to tell me about an interesting use that his team had found for the When clause.

First, to step back, the When clause is an optional Boolean filter expression in a Try/Catch statement that determines whether or not a Catch clause handles an exception. In the following stupid example, the Catch block will only be executed if the value of SomeValue is 10:

Sub CauseException(ByVal SomeValue As Integer)
Throw New ApplicationException()
Catch ex As Exception When SomeValue = 10
' Do something
End Try
End Sub

The use that Matt’s team had found for the When clause was to use it as an efficient way to log exceptions. Without the When clause, the only way to log an exception without handling it is to catch the exception, log it and then rethrow it, as in:

Sub DoWork()
' Do some work
Catch ex As Exception
End Try
End Sub

(Hopefully people are familiar with rethrowing exceptions. A ‘Throw’ statement by itself in a Catch block will rethrow the exception without disturbing all the useful stack trace information stored in the exception. Leave a comment if anyone would like elaboration.)

The problem with this is that you’re incurring extra overhead in logging exceptions this way. The CLR exception model is two-pass. Put simply (which is about the level that I understand it), when an exception is thrown the CLR makes a first pass up the call stack looking for an exception handler to handle the exception. When it finds a suitable handler, it then goes back and makes a second pass up the stack, unwinding the stack up to the point where the exception handler is. When you log exceptions in the above way, you incur the two-pass overhead twice: once to get to the exception handler that does the logging and then again when the logging exception handler rethrows the exception.

A more elegant way of logging, then, would be to use the When clause:

Sub DoWork()
' Do some work
Catch ex As Exception When LogException(ex)
' Do no work
End Try
End Sub

In this example, LogException is now a function that always returns False. The beauty of the When clause is that the CLR executes it as a part of its first pass up the stack looking for exception handlers. So in this case, the When clause will be executed, the exception will be logged, LogException will return False and the CLR will continue up the stack looking for a suitable exception handler. No extra overhead of throwing exceptions twice. Pretty neat!

Ironically, I’m just starting to do some work on the Whidbey VB.NET compiler to improve its integration with the Windows error logging service (you know, the thing that pops up the dialog “An error has occured in foo.exe. Would you like to report the error to Microsoft?”), and it turns out we’re going to end up doing exactly the same thing in C++. Basically, we want to catch an exception that is “in flight,” pass it off to the Windows error logging service and then allow the exception to continue on to be handled elsewhere. The way we do this is, you guessed it, we create an exception handler whose filter expression calls the Windows error logging service and then returns False.

Synchronicity at work.

Changes to XML Documentation comments

Just a quick one… The PDC build of Whidbey has XML Documentation comments in VB that look something like:

'@ <summary>
'@ A method.
'@ </summary>

The “@” was used as a placeholder while we did some testing and discussion about what the marker for the comments should be. An obvious choice would be ”’ (three comment ticks in a row), but we had some concerns that the comment/uncomment block IDE feature might negatively interact with it (i.e. you do “comment block” multiple times on a section of code and all of a sudden you’re getting weird XML Documentation warnings).

However, we’ve decided that we do like ”’ the best, so we’re going to slightly modify comment/uncomment block to add a space after the comment tick to ensure it won’t create XML Documentation by accident. So in the beta, XML Documentation comments will look like:

''' <summary>
''' A method.
''' </summary>

More feedback is always accepted. (Though, please, no accusations that we’re changing the syntax because we think VB developers are too dumb to understand “@”… <G>)

Across the Street and Into Egghead

Doing my maybe-funny satire of the Molson commercial reminded me of something I hadn’t thought of for a long time… Seven or so years ago, there was an internal “Bad Hemingway” contest in the spirit of the various “Bad” contests that were all the vogue at that time. I entered it with the following story. It completely failed to win anything, which calls into question both the humor value of it and the advisability of my posting it here, but what’s a blog good for if not posting writing of questionable value? I promise – this is it in terms of attempted humor writing. There’s a reason I’m a programmer. (See if you can get all the ancient technical references. “AT?“ Does anyone even remember those?)

Across the Street and Into Egghead

In the city of Redmond there stands a cafe that the natives call “Egghead,” meaning “one who is too smart for his own good.” No one knows why they call it that, but the waiters there serve a tall double skinny half-caff latte capped with white foam to rival even Harry’s American Bar and Grill. It is there that the old fighters go to sit and swap tales of happier days, of bits and bytes, of Pentium math errors and offensive dictionary translations, of Gates and his victories.

It was raining, a gray rain pattering down on the soiled concrete like the beads of sweat from a bullfighter’s forehead. Nick Adams walked across the street and into the Egghead. The Egghead was full at that hour of men and women talking the talk of people who did not know pain or want, who had Pentium Pros and knew nothing of the terrible loneliness of getting by on only an ancient AT. Nick sat.

“What would you like, senor?” the old waiter asked.

“OS/2.” Nick replied.

The old waiter laughed and spat insolently.

“We have no OS/2, ingelse.”

“Then I’ll have a Macintosh.”

“I’m sorry senor but we have had none of those since the war.”



Nick tried not to think of the OS war, but it was always there in the back of his mind, like the aftertaste of cheap beer at a frat party. Before the war he had been happy, spending his hours typing on his Apple ][+ and playing Microsoft Decathlon and writing his AppleBASIC programs and it was like being in love for the first time. But now it did not matter. He had lost everything in the war and the memories swarmed around him like flies on a beached whale. He remembered the hard drive crash, the endless “Abort, Retry, Ignore,” the cruel laughter of the men of the PSS, then nothing more. His machine was gone now and he would never have it back.

“Then I’ll have a Windows 95.”

“The Windows 95 is weak and no good, senor. Would you not prefer a Windows NT?”

Nick stared into the dark void that was Microsoft. He longed for a Windows without crashes or bugs, GPFs or hourglasses, one strong enough for a man but made for a woman, a clean, well-written Windows. But the war had settled all that. It did not matter any longer.

“I’ll have a Windows NT, then.”

“Windows! Windows! Windows!” a balding man across the room bellowed like a bull who knows at last that it will die.

“Who is that?” Nick asked as the orderlies dragged the man away.

The waiter sighed the sigh of the old and said “That is Senor Ballmer. Once he was a great fighter and did many great things in the war. Now he sits in the corner and drinks his Starbucks and dreams the dream of Windows Everywhere.”

“How sad.” said Nick.

My name is Mort, and I am a VB programmer…

[Update 11/01/03: Thanks to reader Mikel Berger for a new link that supplies both the audio and the video of the commercial.]

So I was thinking about the whole discussion around refactoring, and parts of it reminded me of this Molson commercial. Unfortunately, most people outside of Canada will never have seen the commercial although it was reported on some around the world after it became something of a phenomenon. In it, a nondescript guy walks up to a microphone in front of a big screen displaying a maple leaf and starts talking. You can check out the commercial here. Which made me idly think of a slightly different commmercial…

(Paul looks thoughful as wavy lines cross the screen and we fade out to the same stage, only this time with a picture of VB being projected on the screen. A nondescript guy comes out and starts to speak, using the same music.)

I’m not a newbie or a script kiddie.
And I don’t get paid less than other programmers, or only work on UIs, or write email viruses.
And I don’t know BillG, SteveB or EricR from Microsoft, although I’m certain they’re really, really nice.
I have a Handles clause, not a += expression.
I speak VB and VBA, not C#.
And I write it ‘For Each,’ not ‘foreach.’
I can proudly type names using any capitalization I like.
I believe in line continuations, not curly braces; colons, not semicolons.
And that ‘With’ is a truly proud and noble statement.
CType is a cast, ReDim IS a statement.
And it IS written ‘Mod’. Not ‘%’. ‘Mod’.
BASIC is the oldest Microsoft language, the most popular programming tool in the world and the best part of Visual Studio.
My name is Mort, and I AM A VB PROGRAMMER!

(Wavy lines fade back to Paul who’s nodding his head as if to say, “Yeah, that’d be cool…“)

Take it for what it’s worth, eh?

Refactoring redux

Now I know how dentists must feel when they’re drilling into the patient’s tooth and they hit a nerve. I think that previous to this I’d gotten at most, what, five or six comments? The refactoring item has 31 comments and counting. Whew.

First, let me say the comments about what refactoring tools are most useful are wonderful and will be passed along. They’re all great suggestions, and the team will be looking carefully at them as we think about what we’re doing in Whidbey. I can’t promise we’ll make everyone happy, but we’ll certainly try (as usual)!

Now on to the question of the name “refactoring”…

I think we should get one thing clear upfront: this has nothing to do with the perceived intelligence or sophistication (or lack thereof) of the average Visual Basic user. Every time I’ve ever had a chance to interact with living, breathing VB developers, I’ve come out of the encounter impressed as to how smart VB developers from all walks of life are. I’m sure we have our fair share of knuckle-draggers in the crowd, but, to be honest, this is the case for all computer languages – programming in C++ does not automatically make you intelligent any more than attending Yale University automatically makes you intelligent (both of these I can attest to first-hand). In my memory, there has never been a situation where anyone from the product team has ever talked about or discussed our customers with anything less than absolute respect. So although there certainly are quarters of this industry that do not treat VB developers with the regard that is due them, I can assure everyone here that they do not work for the Visual Basic team.

To put it even more bluntly: there is no question here of us thinking anyone is too “dumb” to understand anything.

Much of this brouhaha is really my fault in that I didn’t really explain what I meant when I said we “won’t be using the term ‘refactoring.’” I meant it really narrowly, but the way I wrote it I’m not surprised people interpreted it very broadly. All I was trying to say was that it is very likely that we will not be grouping IDE features that could be called “refactoring features” under a menu item that is entitled “Refactor” or “Refactoring.” That’s really it. We won’t have a menu item with the word “Refactor” in it. That’s all. We’re not going to be inventing new jargon to refer to the features, nor will we be hiding the fact that we support features that fall into the “refactoring” bucket. We just won’t have the menu item. (Actually, given the customizability of the VS IDE, you’ll probably be able to create the menu item if you prefer it.)

The VB team is not hostile to the concept of refactoring. Nor do we believe that all of our customers are unaware of the concept and/or have problems understanding it. It’s just that we felt we didn’t need to explicitly call out the fact that “Hey, the following features fall under the rubric of ‘refactoring.’” For example, symbolic rename is a feature that works pretty well on its own. We didn’t think we needed to explicitly link it to the abstract concept of refactoring to draw people’s attention to the feature or to convince them that it was useful.

The other reason I alluded to (and was, I suspect, the really sore point) is that for every developer who is immersed in the love that is refactoring, there are more than a few that aren’t. In fact, I’m one of them. I realize it may cost me some respect to admit this, but I’d never even heard of refactoring until C# added the feature to their IDE. I’ve never bought a copy of, much less read, Refactoring: Improving the Design of Existing Code. This does not mean that refactoring, as a way of life, does not have great merit or that I may not be woefully behind on an important trend in our industry. It just means that before C# added it, I didn’t happen to be familiar with the concept and, although I could be wrong here, I’m probably not the only one out there. (I’ll add that I like to think of myself as reasonably intelligent and well-informed, so obviously those two traits are not something I think are lacking in people who don’t know about refactoring.)

Given that there is some non-zero sized pool of developers out there who are not familiar with refactoring, the question then comes down to how to handle that. One way is to explicitly call out in the menu structure “Hey, these features fall into the category of ‘refactoring’ features.” and then rely on the user to say “Hmmm. ‘Refactoring.’ Never heard of it. I wonder what that is…” and start typing search terms into Google. A lot of developers, especially the professionals who are lucky enough to get to investigate new technology and new ideas as a part of their job, will do this. But there are a lot of developers out there who are going to say “Hmmmm. ‘Refactoring.’ Never heard of it. Crap, look at the time, I’ve got a lot to do before lunch…” and just move along. That’s because they don’t necessarily have the time or the extra available energy to spend exploring the nuances of Visual Studio, not because they are too stupid to figure it out. And, to be honest, for a lot of developers exploring interesting new trends in the computer programming industry is just not the main part of their job. They use VB or C# or C++ or whatever to get some part of their job done and move on. And if we can save them some time and energy by just saying “Here’s symbolic rename.” instead of saying “Here’s symbolic rename, but first I want to tell you about this little thing we like to call ‘refactoring’…”, then I think we’ve done them a favor, not treated them like idiots or children.

Now, if it was the case that helping out these developers would actually cost the rest of the developers something, then we’d have to really wrestle with the question. We do that kind of thing all the time, try and balance features between the different groups of developers that make up our customer base. But in this case, it really seemed like a no-brainer. If you know what refactoring is, you don’t need us to tell you that “symbolic rename” or “extract to method” are refactoring features. You already know that, we don’t need to drill it into your head. So, it’s not clear what harm there is in not having a “Refactoring” menu item as opposed to just showing the features directly.

Now, I realize that not everyone will agree with these sentiments, and that’s entirely OK. Despite the press we get, none of us at Microsoft really thinks we know it all. (Well, OK, maybe Don really does know it all, but he’s not always telling…) I think the feedback you’re all giving us on this issue is really great and we can continue this conversation as long as we need to. I hope this clarifies things a bit more, though.

“Ask a Language Designer” fixed!

Cory was nice enough to point out that my Ask a Language Designer page was broken. You could type in stuff, but when you clicked “Send,” nothing happened. The problem was that in the last blog software upgrade, I somehow managed to delete the “Handles Send.Click” clause from the handler for the button, so nothing was getting sent. It should be fixed now. The way to tell is that if you submit a question and you aren’t take back to the main page by clicking the Send button, then it’s broken. You can always send me mail at if you ever run into problems with the blog. Thanks again to Cory!

As a result, anything that’s been submitted over the past month or so was lost. Please don’t think I was ignoring you, and please resubmit your question!

While I was fixing that, I also made a few minor changes. I stole an intersting idea by Clemens and added a small image bug to the entries in my main RSS and comment RSS feeds. The immediate result is that you’ll get lots of updated entries, but over time I hope I can get a better idea what people read and are interested in. All reporting on the image bugs is an aggregate report (i.e. hit counts) and no other information that that is logged. Feel free to leave comments on this if there are any concerns or problems.