Of course, clicking on the information bar shows the notebook in question, but does not assist at all in fixing the error. I scoured the UI to see where I could enter/update my password, all to no avail (“Notebook Properties” gives me the path to my notebook, but does not have any password configuration).

On the web, I found a possible fix involving IE settings that didn’t work for me. However, another suggestion to reboot OneNote took care of the problem.

No, this information was not helpful in the least. I discovered that the error was a result of Microsoft’s immense Global Address Book. The developers writing the Send error handling could learn from the guys working on Check Names, which results in this actionable text:

I’m a little skeptical that the local Emirates office will be able to track down this null-reference exception for me, though it’s possible they have access to the IIS logs.

When I retried the process, I was listed as “Checked In”, so I suspect the null-ref occurred when they were trying to email my boarding pass. No problem, as Emirates has an option to re-send your boarding pass from their website. Unfortunately, when I tried this path, I received this error:

While factually correct, it is not particularly helpful in getting access to my boarding pass.

It turns out that simply trying again later wouldn’t have helped much, unless I happened to try again later using a string that had neither a hyphen nor an apostrophe in the Name field. Of course.

A better validation message might have read, “The Name field may only contain alphanumeric characters,” or “There are unsupported characters in the Name field.”

Though I hadn’t played with Eclipse Web Services integration before, it seemed like it would be straightforward enough. I downloaded an updated WSDL, added it to my project, right-clicked on it, and chose Web Services->Generate Client.

Not so fast:

Some web searching uncovered that what this error really means is “The Web Services generation tool detected multiple versions of the javax.xml.soap plug-in installed. Resolve this error by removing the conflicting plug-in.”

Sure enough, when I checked in Eclipse there were two versions.

I encountered two speed bumps when testing this theory:

1. There’s no easy way to uninstall a plug-in within the Eclipse UI, so I had to resort to removing the directory from eclipse\plugins directly from Windows Explorer.
2. Which version should I remove? It took me two tries to figure out which version was causing the error. Turns out that newer is not always better…in this case 1.3 was at fault and 1.2 (javax.xml.soap_1.2.0.v200905122109) was the version to keep.

I hit this obtuse exception the other day. The stack had System.Configuration code on it, which is the only way I managed to track it down to a StringValidator attribute. A few things that would have been helpful:

1. Having the name of the culprit in the exception string (i.e. “The string ‘foo’ must be at least 24 characters long.”)
2. Including the configuration element of which string ‘foo’ is a property of (i.e. “The string ‘foo’ must be at least 24 characters long to be used for property ‘bar’ on element ‘baz’.”)

Turns out that this was not actually a .config file error. After subclassing StringValidator and creating a ConfigurationValidatorAttribute to bridge into the declarative system, I discovered that the exception was being thrown while validating the default value.

I had naively thought that if you have a required ConfigurationProperty, then you do not need to set up a default value. I was wrong. I discovered that this is a known bug in the .Net Configuration validation framework that has been resolved “By Design”.

I completely understand why they want to run the validators on default values, but the framework really should check if a property is required and suppress default value validation in that case. As it is, the default value is never used, and the framework properly throws an exception if the required property isn’t explicitly set by the user.

As a result, the following is the “correct” way to have a required property that works with the config validation framework:

[ConfigurationProperty(namePropertyName, IsRequired = true,
// We need to set a default value for our string validator to work
DefaultValue = "dummy")]
[StringValidator(MinLength = 1)]
public string Name { … }

Sometimes I think I should run a signspotting campaign for error messages. In this particular case, the error happens when trying to install or uninstall a Windows service.

Since there was nothing actionable in the error message (sigh), it was off to the web. On MSDN, the only “fix” was to reboot your machine. Boo. Fortunately after digging deeper it turns out that all you really need to do is close services.msc if it’s open.

Given that this is a fairly common situation for services development, hopefully this post will save a few reboots. And maybe the next version of Windows will say something to the effect of “service was unable to install/uninstall because services.msc is open, please close the control panel and retry your installation.”

Any guesses as to what it means?

Here’s the translation from my hosting provider’s support folks:

All operations which you need to perform with the domain should be done with 15 minutes interval. It is bounded on synchronization of your DNS zones on our DNS cluster.

In other words, don’t be so slow. I tried again, following the instructions, and received the same error. Once the support team removed the domain from my user account on their end, I was able to try again with success.

…SYSTEM NOT FOUND. INSERT INSTALL DISC. DISC NOT FOUND. PLEASE CONFIRM DISC COVER IS CLOSED. READ ERROR. INSERT BOOT DISC AND PRESS ENTER. NO RESPONSE. SYSTEM MAY BE BUSY OR MELTING INTO SLAG. APPLICATION ERROR. SAVE YOUR WORK AND QUIT. YOU LOST EVERYTHING. WAY TO GO, GENIUS. WAITING FOR PROCESSORS. “404 computer hamsters not found.” THREAT LEVEL UPGRADED TO JELLY ROLL 1. DETONATION IMMINENT.
         –Fracktail, the first boss in Super Paper Mario. Back story here.

Hello. We are a couple of software engineers from Seattle, currently rounding up a year-long sabbatical spent volunteering in various parts of the Global South. At different points during our year of volunteer work, we have been customers of both our own software (in development, end user, and administrative capacities) and that of other software publishers. It has been an excellent opportunity to get a little bit of distance from our day-to-day responsibilities and to reacquaint ourselves with software experiences from the user’s point of view. In the process, there have been many situations in which we have become very, very frustrated. Quite a few of these cases have involved extremely bad error UI, in which the error message or mode fails completely at communicating what has gone wrong and what must be done to correct it. In such cases, we have often had to resort to the internets for the answers, with varying success. Kenny has posted about a few of these experiences on his personal blog, and has received effusive notes of gratitude from other poor souls who encountered the same problems and were saved further headaches by his advice.

Thus the idea for this blog was born. We plan to post examples of egregious error messages and experiences, not only as a means to vent our frustration, but hopefully also as a resource for others who may encounter the same issues. In the process, we’ll poke a little fun at the authors of the software, who were doubtless under tight deadlines drowning in a sea of high-priority bugs, but we figure they deserve a bit of ribbing for failing to adequately appreciate or understand their end users.

Of course, it would be naive to believe that anyone can design programs – or users – that never fail. But we both firmly believe that most software developers, designers, and UI editors do not devote enough attention to how their software fails. Is it graceful, with a clear and actionable error message, whose instructions accurately identify the source and the remedy for the failure? Or does it leave the user frustrated and indignant, with large bruises on his forehead and dents in the wall from too much head banging?

On that note, I expect that we will also post examples of good error behavior from time to time. But not that often, since it’s less fun to post things we can’t make fun of.

We hope that you enjoy this blog, and we’d love to include your contributions. Check out the Submit an Error page for instructions on how to send us your favorite misleading error dialogs and exceptions. Bonus points will be awarded for relevant submissions that are not related to software.