Shey’s Rebellion

As software developers we make dozens of design decisions daily, some are more subtle than others.  Recently, I briefly reconsidered returning error values instead of exceptions to signal error conditions.

As a general rule my policy is to throw exceptions except when I’m the only consumer of the method and if I am the only consumer of the method it is sometimes OK to return a BOOLEAN value to signal success or failure.

The obvious reason to avoid exceptions is that they are invisible in the source code, especially in C#.  Looking at a block of code there’s no way to see which exceptions will be thrown and from where. Exceptions also create too many exit points from your function, and as a programmer you must be aware of all of them.  Finally, your program takes a small performance hit when you use exceptions because exceptions throw off the stack frame.

I’m still inclined to continue using exceptions.  Anyone who has worked on applications with several developers knows how difficult it is to maintain functions that return error values– as the program grows developers add new return values and it’s not easy to determine which error value corresponds to which error condition.  Using return values to indicate errors leads to software that is more difficult to maintain.

Exceptions also force the caller of your method to deal with the exception, it is very easy to ignore return values, and an unhandled exception will stop your program from executing.  Additionally exceptions let the developer choose where the error should be handled.  Code can be written to catch exceptions near the failure point, or further up the stack.  With return values your error handling code must be near the point of error; often the mechanism to deal with the error (i.e.: the user) is not available at the point of failure.

This being said, I’m not advocating throwing generic exceptions, you as developer must consider how your code will be used and throw exceptions which properly convey the type of errors your method may encounter.

Using exceptions instead of returning error values allows your program to be more flexible and easier to maintain, I can’t think of any good reasons to stop using exceptions.  What are you opinions?

Tom’s talking ’bout his role at his job and I’m still not sure if I really know what he does at work, but his post reminds me of the “5 things you didn’t know about me” meme which was so popular several months ago; in honor of that meme, and because bloggers love talking about themselves I’m tagging Ben and James with the “What do You Do?” meme.

Let me start:

I’m a senior software engineer at a small software development company in Karachi. Most of my work revolves around integrating third party applications, i.e.: Project Server 2007, with Microsoft Dynamics Navision 4.0 (an ERP) and customizing different modules and reports in Nav. I also spend part of my time working on ASP.NET applications and writing Perl scripts to automate Navision migrations.

I use the same development tools that you use, Visual Studio 2005 and jEdit for my editors/IDE, SVN for source control, MbUnit for Unit testing, WATIR for web application testing. The only uncommon tool you’ll find on my computer is Beyond Compare—THE single best file and directory comparison utility I’ve ever used.

So, what do you do?

I’m a big fan of Unit Testing, even more now that I’ve upgraded to MbUnit, it’s certainly much easier to test the data access layer with MbUnit, but I’ve found it nearly impossible to unit test my Project Server interfaces, I don’t know how to undo an insert/update in Project Server, has anyone figured out how to rollback transactions on Project Server using a Unit testing framework?

I’ve been incredibly busy at work again and instead of writing something coherent I’ll just dump my brain in this post. I’ve also developed a very severe case of Nerd ADD.

Earlier this week I hit a snag in my Project Server/Navision integration, lets just say that portions of Project Server’s web service isn’t documented very well. I wasted a lot of time trying to figure out researching exactly which functionality the Time Sheet web service exposes; it wasn’t until I found an example on Christophe Fiessinger’s Blog that I finally figured out what I wanted.

Working with Project Server has gotten me excited about programming languages again and I want to learn C# 3.0 and Ruby– C# has gone through some major changes, they’ve added extensions which are similar to Ruby mixins, lambda expressions and anonymous variables, it’s a completely different language now, much more flexible, much less like Java and much more like Ruby.

Tenerife Skunkworks, a Erlang blog has peaked my interest in Erlang and day trading in general. In my former life I was a quant in training and a software developer working on an algorithmic trading platform. Algorithmic trading is resource intensive and our system distributed ‘jobs’ over several computers to manage the processor load, looking back I wish I programmed the core of the system in Erlang instead of C++. That’s hindsight for you. I’d like to get back to my ‘roots’ and work with financial systems again, maybe the FIX protocol or a trading simulator or platform, I should spend some time searching for open source projects that I could get involved in.

I finally got around to installing an evaluation copy of Resharper– I’m disappointed, maybe my expectations were too high, or I haven’t had enough time to use it– while it’s an improvement over the default VS 2005’s interface it still falls behind Eclipse’s refactoring code generation. Does anyone have any Resharper tips for me?

Definitely a severe case of Nerd ADD.

A state of emergency has been declared in Pakistan, the country’s constitution has been suspended, all news channels including the foreign news outlets BBC, CNN, Sky News and Al-Jazeera except the state run PTV are off air.

Edit: Under the Provisional Constitution Order the following articles have been suspended: 9, 10, 15,16,17,19 and 25. These articles include the following rights:

• Security of person
• Safeguards as to arrest and detention
• Freedom of movement, etc.
• Freedom of assembly
• Freedom of association
• Freedom of speech, etc.
• Equality of citizens

Ben’s arguing in favor of fluent interfaces and higher levels of abstraction and I completely agree with him, working at higher levels of abstraction makes your more productive and DSLs play an important role in problem abstraction.

The trend seems quiet obvious, programming languages are headed towards higher levels of abstraction and specialization, SQL is a perfect example of a high level language that is designed for a specific task. It has a specific purpose, retrieve data from relational databases and it does it well. New languages will cater to a specific domain, some languages will focus on UI development while others may help you create work flows easier.

As developers we should embrace tools that help make our work easier. Having several tools (languages) at your disposal can make solving a complex problem easy, if the language is designed with that problem in mind. Ben mentioned Erlang, a langauge which provides a better solution to concurrent programming problems. Erlang is designed to take advantage of multi-cores; you as a software developer want to create applications which use multi-core cpu fully; currently, it is quite difficult to create such an application Java/C#/Ruby/Python.

As Ben says, don’t fear the abstractions!