Musings from the Trenches


The unbearable lightness of errors

By Chris Douce

Due to various policy decisions recently made by a major operating system vendor, a number of different integrated development environments (IDE's) were evaluated. These ranged ranged from those that were open source and freely available for use, through to very expensive (and supported) commercial equivalents.

One of the most striking differences between IDEs and their compilers was not the immediate differences in the screen layout - a change in design of a code explorer window - or the differences in the short-cut keys, but the differences in the compilation messages that were produced when code is compiled.

Leaving one IDE for another can be either a painful or enlightening experience. Not only do you loose the location of toolbar icons and menus learnt over several years, but also your ability to interpret the error messages that a new environment or compiler generates.

Rather than a producing a message stating, 'semicolon missing at line n', compilers often generate scroll-boxes filled with messages that have little bearing on what amounts to a very minor syntactical lapse.

I remember, as a beginner, being absolutely terrified by the screen scrolling past, generating acres of pages in response to an incredibly trivial error. My mentor sitting behind me would chuckle, wander over to my PC, move the cursor to a line that was close to the first error message and add my omitted semicolon, much to my astonishment.

Bracketing and braces are also common causes of a catastrophic cacophony of errors. A message telling you of an unexpected closing brace, really means that you have forgotten to put down an opening brace somewhere. Miss off a parameter and you may be told that you have an 'unexpected ")"' Cognitive psychology texts tell us that negative information is more difficult to comprehend.

When often presented with hundreds of small, all intricately related error messages, I get a 'feeling' for the original error, based upon the form that the messages take.

Changing your IDE changes the way you respond to your own mistakes. Your 'error schemas' which fire when seeing the keywords similar to 'unbounded' or 'inheritance' may have to be reformed as you feel your way around your new IDE. At the same time you may even changing your model the language that you use.

Working with a compiler and responding to compilation messages can be viewed in terms of having a 'conversation' with a body of source code. On some occasions I have felt it helpful to deliberately introduce errors to observe the effects on some alien code.

I have renamed objects, classes and even files in moments of frustration to attempt to get snippets (or slices) of information about the inner workings of some undocumented software project undergoing maintenance.

When an IDE or compiler changes, so does its personality, so does a developers mode of communication with his or her unknown mass of symbols and instructions.

Are you working in industry and would like to tell us about an issue that you feel particularly strongly about? Is there something that you feel that the academic computer science, software engineering or human-factors communities should be addressing? If so, please do tell us!