There is a lot of confusion about writing your own exception classes. I see far too much code out there that just catches "Exception" anyway, that I hate to complain about someone who has set themselves up to have different catch behaviour for "The server is probably offline" than for "you probably don't have permissions on that file you just told me to use". However those who write their own exceptions have generally derived them from ApplicationException. If you ask why, they say things like "well" and "er" and "um" a lot because there's no extra stuff in an ApplicationException compared to an Exception. It just made it possible for you to catch "ApplicationException" and know it would be one of yours and not from some framework code.

Only thing is, that didn't really work out -- some framework code throws exceptions that derive from ApplicationException. And really, catching ApplicationException is just as generic as catching Exception. What can you meaningfully decide to do when all you know is "some code I wrote is unhappy in a way that the built-in exceptions (invalid argument, access denied and so on) cannot properly express" ?

So the word is out. Don't inherit from ApplicationException. Got it.

Kate

Here is something really cool. If you happen to hold Shift while you right-click a file in Windows Explorer, you get more options on the menu:

The one I'm most likely to use is Copy as Path. Lets say you've just put a file on some shared drive somewhere and now you're emailing someone that you've done so, or you're passing the full file name to another application, or you're recording the file name in the files itself so that printed copies make sense. You need to copy the path from the address box, then the file name - it's annoying. This little trick doesn't save a ton of keystrokes, but I like it.

Kate

Recently we took a large SharePoint project live at a company that is acquiring others quite fast, and having trouble keeping its Active Directory situation up to date as new domains are assimilated. When the project first went live, everyone had to authenticate to the server when they first browsed to it, and in some cases a second or even third time, depending on what kinds of files they opened, whether they followed links to other internal servers, and so on. As you might imagine there were plenty of complaints from folks who didn't like having to authenticate all the time.

We as the developers couldn't do a lot about this, but we worked hard with their IT folks and did a few clever things of our own until we achieved single sign on glory. Workers throughout this global firm would sign in to their own Windows desktops, and from then on everything in their whole intranet was theirs with no more authentication needed. Of course it was all strictly controlled - only HR people could see the HR files, only Finance people could see the Finance files, and so on. But it was perhaps a little too transparent. After we achieved this lovely state people stopped emailing to complain about authenticating, only to be supplanted by a new chorus of complaints from people we hadn't heard from before. The most poignant read simply "Everyone can see all my files!" and was accompanied by a screen shot of a browser opened to the HR area. Our correspondent hadn't been challenged for a password and was therefore sure all these files were completely unsecured. It took an in-person visit that included "why don't we go over to Bob's desk so you can see what the portal looks like for him?" to finally convince this user that invisible security is still security.

For all I know, there are scores or even hundreds of people in that firm who don't realize their sensitive information is protected. Typing in a password annoys many users, but it soothes others.

Kate

I got a real aha moment when I saw this graph:

The blog post where I saw it was talking about "management by ..." but I think it also applies to the motivation that individuals are moved by. That is, relative newbies to a job tend to do things a certain way because those are the rules. As they progress over time, most of them move on to "this is the method I use" and then to "my team's objectives are" and finally "this is what my team values." I think this is a hugely important progression to understand.

Let's take one little thing, say source control behaviour - do you check in too often, not often enough, are your comments any good, are your changesets too big or too little, and so on. If I want to direct your source control behaviour I need to know what zone you are in.

• If you're in the "rules" zone, I must tell you the rules for source control. I need to write a long document with lots of examples and if there are exceptions, or different rules for different projects, I need to elaborate them all. Whenever you do something "wrong" I will probably hear that you were just following the rules, and I will need to update the rules to attempt to prevent that problem in the future.
• If you're in the "methods" zone, I must cover source control in the documentation of my methodology, put it into context, show you why we use it and how things you type at step 17 will be used by someone else at step 35. The rules don't need to be so black and white or so detailed, but there may need to be different methodologies for different kinds of projects or circumstances. If I correct you I am still likely to hear that it's because the methodology is flawed.
• If you're in the "objectives" zone, I need only remind you that we need to be able to pick up projects again for a version 2 long after we shipped version 1, or that we need to be able to recover from two people editing a file at once, or that we need to be able to explain to clients which files are different in version 2.3.4 than they were in 2.3.3. The detailed rules can go; you will choose your changeset size and your comments knowing which of our objectives you are supporting when you do so. If you make an incorrect decision and I point it out to you, your response is most likely to be "oh" and then you will adjust your own internal set of rules and methodologies accordingly.
• If you're in the "values" zone, it's even simpler - we value making money on each project, and serving our clients well, and you know that, and you have the capability to make the right decisions in order to support those values. I barely have to manage you, just provide you from time to time with information.

In contrast to the blog where I found this graph, I don't see it as just being a matter of how managers choose to manage their projects and people. I see that some people cannot be motivated by values alone, or objectives alone. Either they lack the career maturity to recognize that supporting the team's objectives is always in their own self-interest, or they lack the skill and knowledge to choose correctly (should I check in now? or wait till I have tested? or wait till I do those other changes?) knowing only what outcomes are important to the team.

I personally don't care for the rules-oriented phase. Writing out exhaustive "if this happens do that" documents is not really fun work. Hearing that a flaw in the document is why something went wrong also doesn't really work for me. Yet it seems all team members (and by this I mean not just my own staff, but my clients and their staff, other vendors, and so on) need to go through this phase when adapting to a new process. Well, knowing it's going on makes it easier for me to cope with it.

Kate

Here is a neat thing i actually learned about from people complaining about Vista performance. I haven't been having performance problems to speak of (except for that darned copying thing) but I was intrigued to hear about a background process that keeps track of how stable your system is. The Reliability and Performance Monitor is tucked away under a zillion menu options (this blog post leads you there) but I just click the marble and type reli and there it is:

The first thing you get is a performance monitor-type view, to do with as you will:

But if you click reliability monitor, you get something really quite new:

Here you see things the system feels were instabilities in my system in late May and early June.  Mind you, it has a very persnickety bar when it comes to those red Xs.

On June 1st, Visual Studio blew up on me. I bet I know what that was, too -- from time to time it blows up when I drop down a list of methods in those bars across the top of the code editor, especially if I try to scroll in the dropdown -- and not only was that recorded, but it contributed to a lower "stability index" for the day. As you can see, the system also records everything I installed (including updates through Windows Update) and everything that failed. It's a pretty neat way to remind yourself what you've been going through. You can also validate wild claims like "Project blows up at least once a week" by scrolling back and counting them. Ah, evidence

Kate

I was helping a mentoring client translate some sample code from VB to C# - he has written a lovely library and a customer wanted to see C# code that called it. The original samples had been written by someone who wasn't in the room, so I could have a bit of a vent. They had made heavy use of the Microsoft.VisualBasic namespace (nothing wrong with that) so as to access familiar (to a VB6 programmer) string manipulation methods. The problem was, these methods were being used to do things like finding the extension given a file name, or extracting a file name from a long path. This work should never be done with Left, Right, and Mid - and using Substring doesn't make it better. There are all kinds of methods in System.IO that manipulate paths and file names in a more robust and localized way than you can possibly do by hand. For my client's code, I ripped out a whole pile of hand written code (including a loop that looked character by character at a string testing to see if each was '\' or not) and replaced it with calls to library methods.

Phil Haack lists a bunch of these (and his commenters even more) in a very useful post. Developers who know what's in System.IO and the other meat-and-potatoes parts of the .NET Framework will write code more quickly, and that code will be better. Never assume you're the first person who wanted to parse a file path, check if a string is a good date, or any of a thousand other general tasks. Trust me, what you want is in there ... look for it.

Kate

I brought home a paper copy of MSDN magazine from Tech Ed and found this as one of the cover stories: An Inside Look At The Next Generation Of Visual C++. It's by Tarek Madkour and definitely worth a read. Were you wondering if MFC's wrapper for the new file dialog would be tweaked so you get the all-singing all-dancing new Vista common file dialog? Yes it will. Will there be a class to represent a Command Link? Yes. And a split buttton? Yes. Pretty much all the new controls and dialogs are in the new MFC. There's also resource editor support for PNG, for 32 bit images, and for large icons.

As I mentioned in my blog post about Sarita's Channel 9 Video, UAC support is also a lot easier. Then there's the marshaling library and STL/CLR. Toss in faster builds, and make developers everywhere happy. Roll on, release day.

Kate

Herb Sutter reports on the April meeting of the ISO C++ standards committee. They are now consistently referring to C++ 09 not C++ 0x (with a hope that x would not be hex, which seems to be turning out ok.) The meeting added features to the draft standard for the language itself (template aliases aka typedef templates, variadic templates, and unicode) and for the standard library (variadic templates, unicode, and rvalue references.)

The next meeting is July 15th - 20th in Toronto. I am trying to plan to be there.

Kate