On the Lack of Exceptions

August 9th, 2007

Lately, I’ve been helping develop a reasonably sized application, which detects errors at every operation. Checking the return value of every function call seems awkward when compared to code that is written in rather informal working environments. Writing code that checks each return value is frustrating when a feature that exists in another language is not available in the current implementation language. A function signature that may allow for the detection of a function’s failure is as follows:

STATUS operation( ArgType1 arg1, ArgTypeN argN );

The only qualm I have with the above function signature is that operation() is inconsistent with the mathematical notion of a function. Instead of having y = f(x), where the parameters to f() are unchanged, the function signature above has a return value set of {SUCCESS,!SUCCESS}, and the result of the operation may be stored at a memory location that is passed as an “out” parameter. Although operation() is less function-like, I like this method more than the use of global variables and additional function calls for error checking.

An apparent problem, or nuisance, occurs when multiple calls to operation() are made and error checking with handling needs to be performed. The code becomes saturated with conditionals and possible duplication of error handling code:


if( SUCCESS != operation(arg1,arg2) )
{
	/* error_handling_code_1 */
}

/* omitted_code_1 */

if( SUCCESS != operation(arg3,arg4) )
{
	/* error_handling_code_1 */
}

/* ommitted_code_2 */

if( SUCCESS != operation(arg4,arg5) )
{
	/* error_handling_code_1 */
}

This situation is just screaming for the use of exceptions. Exceptions would allow the code to be easier to read, and the implementation of the error handling code can be more disjoint from the function call that is experiencing the error.


try
{
	operation(arg1,arg2);
	/* ommitted_code_1 */
	operation(arg3,arg4);
	/* ommitted_code_2 */
	operation(arg4,arg5);
}
catch( ExceptionType1 arg )
{
	/* error_handling_code_1 */
}
catch( ... )
{
	/* if a given exception is not handled here, */
	/* it may be possible to rethrow the exception */
}

Although the target system might not have exception support, having to implement the discussed code helped me appreciate exceptions.

Transitions

July 14th, 2007

Transitions are always difficult.

While in Deutschland

June 18th, 2007

bundesflagge.gifI have been at Germany for two weeks out of the last month. I took on a task that I thought was theoretically possible, but one where completion under given time and resource allocation constraints was uncertain. The situation called for code developed in a proprietary environment for many months by many people to be ported to another proprietary environment. I took advantage of several software engineering methods, many that I have read about and adopted, to bring about success.

Success in this task was based on several factors that were set in the past. Many of these factors were not and could not be influenced by me. For example, the decision to adopt a highly portable programming language was crucial in the success and ease of the porting effort. Development of the code base started long before I joined the team, and I am glad that the team was steered toward the currently used programming language. Porting an application that is implemented in Visual Basic to a Unix-like environment seems more daunting or even impossible than porting a program that is implemented in C from a Microsoft Windows environment to a Linux environment.

The power of abstraction, interfaces, and separation of concerns were evident in the somewhat rushed porting effort. A well-defined interface of the source environment eased the implementation of the interface within the destination environment. Porting the code was a task of implementing the code’s functional dependencies. After the porting effort was completed, any and all code that is implemented for the source environment could be introduced to the target environment with little to no changes.

I tapped the help of several specialists of different facets of the code base. Specialists of the tools were also helpful. Without their help, the porting effort would have failed. Two weeks is simply not enough time to learn all the details of the code base and source environment, and implement the needed constructs on the target environment. People provided assistance in the form of functional implementation, problem diagnosis, and code examples. We brought about success together. This effort has provided me with a lot of experience, and I hope to find time to write up a couple of postmortems and share the methods that I used to help bring about success.

Configuring the Mouse Scroll Wheel

May 10th, 2007

Having packed my stuff just in case the Griffith Park Fire of ’07 drew closer to home, an opportunitity was created to rearrange my workspace. Rearranging my computers has allowed me to connect a keyboard and mouse directly to one of my principle development machines. I have been interfacing with the machine through VNC up until now, and I just noticed that the scroll wheel was not responsive when I was browsing the Internet with Mozilla Firefox. I spent a couple of hours trying to get it working, so here is my /etc/X11/xorg.conf file that allows my Logitech MX300 Wheel Mouse on CentOS 5 running X11R6 to function:


# Xorg configuration created by pyxf86config

Section "ServerLayout"
        Identifier     "Default Layout"
        Screen      0  "Screen0" 0 0
        InputDevice    "Keyboard0" "CoreKeyboard"
        InputDevice    "Mouse0" "CorePointer"
EndSection

Section "InputDevice"
        Identifier  "Mouse0"
        Driver      "mouse"
        Option      "Device" "/dev/input/mice"
        Option      "Protocol" "IMPS/2"
EndSection

Section "InputDevice"
        Identifier  "Keyboard0"
        Driver      "kbd"
        Option      "XkbModel" "pc105"
        Option      "XkbLayout" "us"
EndSection

Section "Device"
        Identifier  "Videocard0"
        Driver      "nv"
EndSection

Section "Screen"
        Identifier "Screen0"
        Device     "Videocard0"
        DefaultDepth     24
        SubSection "Display"
                Viewport   0 0
                Depth     24
        EndSubSection
EndSection

Effects of Explosions on Schedule Goals

May 7th, 2007

explosion.jpgThe completion of a task was scheduled for 3:30pm. We have been pretty good at estimating the time that tasks require, and we have exercised practices that helped ensure that we meet our schedule predictions. We were fairly confident that we were going to complete our task at the desired time, until the lights flickered and dimmed. The fire alarm sounded moments after. The completion of our task at our planned time was ultimately thwarted.

At 3pm on Wednesday of last week, a transformer that supplies power to our building exploded. All of our workstations and servers use backup power supplies, so the loss of a work day was prevented. I am glad that the UPS for my workstation was set up. We saved our work and performed graceful shutdowns on our servers. We would be able to continue our work where we left off when the power is restored.

Everyone in the office building exited to the parking lot. Firefighters came and immediately created a perimeter around the transformer. Many people had left to enjoy the remainder of the shortened workday, while others, like Chris and me, were still deciding on what way to spend the rest of the day. Some people were discussing their plans next to the defunct transformer. As Chris and I started toward my car, a flash of light caught the corner of my eye, and I heard a thunderous sound and turned to see a fireball rise above the transformer. The transformer, or perhaps a second transformer that shares the same housing, exploded with people around it. At that time, people felt it was unwise to stay next to the transformer and moved away from it quickly. Fortunately, no one was hurt.

A couple of lessons were learned that day. Firstly, even schedules that have a very high probability of being met may experience some slippage caused by external, uncontrollable factors. Secondly, loitering around a transformer, especially one that is known to explode, is not a great idea.