November 2007 - Posts

• Smalltalk: "Been here, done that"

  The .NET world is eagerly anticipating the release of version 3.5 of the .NET Framework and Visual Studio 2008 later this month. Naturally there is a build-up of technical discussions, events and online material about the features the new release is adding to the table. In the meantime, here I am studying Smalltalk, an object oriented language dating back to the 70s. I was still an avid watcher of Sesame Street that time! Will I just let the computing world pass me by as I dabble in programming nostalgia? No way. In fact, many of the touted features for .NET 3.5 (and C# 3.0) as well as Java 7 have been in Smalltalk since it came out of Xerox PARC. LINQ, you say? What about wantedPeople := allPeople select: [ :person | person name beginsWith: 'J' ]. Extension methods? Hey, the entire Smalltalk virtual machine is extensible and you can modify the thing as it is running. I remember all the talk about "Edit and Continue" in Visual Studio 2005...Smalltalk oldies must have been yawning and saying, "Been here, done that." Couldn't believe that your cutting-edge .NET technology has a signboard saying "Welcome to the 80s" around it? See it for yourself. Download Squeak, an open source implementation of Smalltalk. Take a look at the tutorials. Watch a video of Smalltalk in action. .NET developers, it's time to come out of your shells. Welcome to the 80s.   Posted Nov 07 2007, 02:58 PM by cruizer with 19 comment(s) Filed under: General, OOP, development tools, Smalltalk

• InvalidOperationException when accessing a web service

  We encountered a strange thing in our current project: there are times our client will bomb out with a web exception when a web service call is cancelled. We found it strange because we enclosed our web service call within a try-catch block, specifically looking for a WebException and testing if the WebException's Status is WebExceptionStatus.RequestCanceled. (Yep, that's a single "l" alright) If the status is RequestCanceled, that means that the exception was just a result of the cancellation of the web service call, not a real exception such as a timeout. It turns out that the catch block isn't being called because what is being thrown is not a WebException but an InvalidOperationException! This exception, from my observation, is sent when the XML deserializer encounters an invalid XML fragment simply because the connection was cancelled and therefore the XML string is incomplete and malformed. After discovering this, we just added another catch block to look for an InvalidOperationException. Inside this catch block we treat the situation similarly as if we caught a WebException with a Status of WebExceptionStatus.RequestCanceled. After the change, we didn't have problems with it anymore. I plan to clean this up by introducing a helper method where I can pass an anonymous delegate for performing the operation and an anonymous delegate for handling the call cancellation, just to get rid of the unsightly try-catch constructs. So, could this be a .NET bug? Posted Nov 06 2007, 12:15 PM by cruizer with no comments Filed under: DotNET, .NET, services