Don Box provides a succint summary on the whole SOAP vs. REST debate. I couldn’t agree with him more!
Browsing Posts published in February, 2006
Something that I’ve always liked about the Windows NT platform and the .NET Framework is their excellent support for Unicode. Historically programming has been (and continues to be) very English-centric. This is not a problem for me as my native tongue is English, but I’ve learned a smattering of other languages over the years… French – I’m Canadian, eh!, Latin, I’m a geek, eh!, American Sign Language, that’s just cool, eh! I consider myself a multi-cultural person and can only imagine the huge language barrier that software development must present for non-English speakers. Abhinaba has an example of using Hindi variable names in a simple C# progam to show that the C# compiler supports Unicode. This looks so foreign to my Anglophone eyes, but is cool nonetheless. I like his idea of localizing the C# language itself by modifying the C# tokenizer in Mono. This would open up the world of programming to a much wider audience.
For the true geek, consider this… there is a mapping of Klingon to the Private Use Area of Unicode. With suitable modification of the C# tokenizer, you could write an awesome first-person shooter in Klingon. Unfortunately Klingon# (or K# for short) would only compile applications involving serious bloodshed and gratuitous violence. Any other applications would result in a compiler error.
We’ve just released Episode 3: Powered by Infinite Improbability Drive. So that we can get you, our loyal listeners, the episodes more quickly, we’ll be hosting on both MSDN Canada Community Radio as well as on the Plumbers @ Work site. You can find the show notes here, photos here, and podcast here. It will be posted to MSDN Canada Community Radio shortly.
Show Notes
- Introduction
- Around the Horn with the Plumbers
- Security March with Dan Sellers
- Microsoft Blacklisted C++ Libraries
- SHA-1 Discussion
- Team Foundation Server (TFS) Release Candidate (RC) 1
- Public Release of Internet Explorer (IE) 7.0 Beta 2
- Various Issues with IE 7.0 Beta 2
- Development of IE versus Development of Firefox
- The Browser as a User Experience (i.e. AJAX)
- Really Simple Syndication (RSS) in IE 7.0 and Outlook (AKA, The Ultimate Pull Application)
- Information Overload (AKA, Organizing Information)
- Upcoming Canadian Conferences: VSLive! and DevTeach
- Half-Time
- .NET Framework 2.0 Adoption
- ASP.NET 2.0 Adoption
- PetShop 4.0 Discussion and Highlights
- .NET Nuke 4.0
- Old Microsoft Reference Applications (AKA, “Different Strokes” or “ALF”)
- Enterprise Library 2.0 Highlights
- Windows “Live” Highlights (i.e. Domains, Favorites, and Messenger)
- Other “Live” Projects (Office “Live” and Visual Studio “Live”)
- Windows OneCare Beta
- The Realities of a “Secure” Operating System
- Windows Vista Favourite Features
- Running as Standard User/Non-Admin on Windows Vista
- Event Viewer in Windows Vista
- Windows Calendar (WinCal) in Windows Vista
- What’s Coming Up for the Plumbers
- Upgrading to Community Server 2.0
- John Still Doesn’t Have a Xbox 360
Show References
Rory Blyth and the Ewok
The SharePoint Show
Alberta .NET User Group
Calgary .NET User Group
Dan Sellers’ Blog
MSDN WebCasts
Saying Goodbye to an Old Friend (Michael Howard)
Bruce Schneier
SHA-1 Broken (Bruce Schneier)
KeyLength.com
Michael Howard’s Blog
Team Foundation Server (TFS) Release Candidate (RC) 1 (via Jeff Beehler)
Rob Caron’s Blog
Jeff Beehler’s Blog
Team Foundation Server (TFS) Go-Live License
TFS Blog
Internet Explorer (IE) 7.0 Beta 2
Scott Hanselman’s “Running Internet Explorer 7.0 Beta 2 without installing it.” Post
DevConnections
VSLive! Toronto
DevTeach
MSDN Article for Petshop Migration
.NET Nuke
Enterprise Library 2.0
Windows “Live”
Microsoft Gadgets
Windows “Live” Domains
Windows “Live” Favorites
Tuscany (AKA, Visual Studio “Live”)
Windows OneCare Beta
Windows OneCare Pricing Announcement
TopDesk
UntitledNet (Xbox 360 Locator Application)
You can post comments in the forums. As always, feedback is more than welcome.
When reviewing code, I often encounter problems in the way that exceptions are handled. I’m not going to cover guidelines for designing your own exception hierarchy or whether you should derive from ApplicationException or Exception for custom exceptions. (You should derive from Exception, if you must know. There is really no reason for ApplicationException and was a design goof by the BCL Team, as noted in .NET Framework Standard Library Annotated Reference Vol1.) Here’s five code samples showing improper exception handling and how to fix it. We’ll start from the most severe and go to the more cosmetic…
Code Sample #1:
try {
// code
} catch (Exception e) {
// better do something here
}
Whoah!!! We’re losing the exception completely. This is also known as swallowing the exception. This is really bad. If an exception is ever thrown, we’ll never hear about it. Even with the best of intentions, it’s too easy to forget to go back and fill in these types of placeholders. If you want to note that an exception handler needs to be implemented, I would recommend the following code instead:
try {
// code
} catch (Exception e) {
// TODO: better do something here
throw;
}
The TODO will highlight this code in the TODO list in Visual Studio. The throw repropagates the exception so we don’t lose it. We can remove the throw later if we actually handle with the exception.
Code Sample #2:
try {
// code
} catch (ApplicationException e) {
if(e.Message.StartsWith(“Some custom error message thrown by another piece of code”)) {
// Handle the exception
} else {
throw;
}
}
YIKES!!! This code is wrong for so many reasons. Simplest is that your error handling code will fail if you correct (or introduce) a typo in your other code’s error message and you don’t get any compile-time checking. It also breaks horribly as soon as you internationalize your error messages. If you need to handle a particular type of exception, derive a new exception type. If you’re using Visual Studio 2005, there is even a code snippet for new exception types. Simply create a new file, delete the class definition, and type “exception-TAB-TAB”. Presto new exception type. You can then explicitly catch that exception as follows:
try {
// code
} catch (CustomException e) {
// Handle the exception
}
Code Sample #3:
try {
// code
} catch (Exception e) {
throw new ApplicationException(“Some useful message about what we’re doing: ” + e.Message);
}
Whoah again. We just lost a lot of information about the original exception, including its stack trace and any inner exceptions it contained and made our debugging lives a lot harder. I would recommend the following code instead:
try {
// code
} catch (Exception e) {
throw new ApplicationException(“Some useful message about what we’re doing”, e);
}
This code propagates the original exception as the innerException so that we can see the exact origin of the failure.
Code Sample #4:
try {
// code
} catch (Exception e) {
// do something like logging
throw e;
}
This naively looks like reasonable code to repropagate an exception, but it contains a subtle flaw – you’re killing the stack trace. The correct code is:
try {
// code
} catch (Exception e) {
// do something like logging
throw;
}
A simple throw causes the current exception to continue to propagate including stack trace. You have to watch that your logging or other operations don’t throw an exception that can kill the current exception.
Code Sample #5:
try {
// code
} catch (Exception e) {
// Execute code, but never use e, which causes a “variable, e, never used” warning
}
This is minor as it only produces a warning, but if you’re not going to use the variable, don’t declare it! The following code has exactly the same behaviour, but does not produce the compiler warning resulting in easier to read build output.
try {
// code
} catch (Exception) { // We don’t need to refer to Exception, so don’t give it a name
// Execute code
}
or alternatively:
try {
// code
} catch { // We don’t need to refer to Exception, so don’t give it a name
// Execute code
}
This is just a sampling of common problems with exception handling code that I’ve encountered during code reviews. Please feel free to add any additional ones in the comments. Happy exception handling!
Bil Simser has a great blog post on getting Windows SharePoint Services v2 and SharePoint Portal Server 2003 set up for development in your favourite virtual environment. Given that I’m just doing the install dance with WSS v2, this is great info. I’m taking a twist and seeing if I can get things going with VS 2005 compiling to .NET 1.1 using some MSBuild tricks. I’ll report my success/failure in a few days time.
Bil Simser is looking to upgrade from his current status as SharePoint MVP to the world’s first ever Notepad MVP. Support his cause and wish him luck! You go, boy!
.jpg)
