About

I'm Mike Pope. I live in the Seattle area. I've been a technical writer and editor for over 30 years. I'm interested in software, language, music, movies, books, motorcycles, travel, and ... well, lots of stuff.

Read more ...

Blog Search


(Supports AND)

Google Ads

Feed

Subscribe to the RSS feed for this blog.

See this post for info on full versus truncated feeds.

Quote

Once a group gets large, it has to dumb down. We know this with regard to corporations. Same rules apply to religions.

Paul Denlinger



Navigation





<January 2015>
SMTWTFS
28293031123
45678910
11121314151617
18192021222324
25262728293031
1234567

Categories

  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  

Contact

Email me

Blog Statistics

Dates
First entry - 6/27/2003
Most recent entry - 1/22/2015

Totals
Posts - 2321
Comments - 2508
Hits - 1,704,948

Averages
Entries/day - 0.55
Comments/entry - 1.08
Hits/day - 403

Updated every 30 minutes. Last: 11:00 PM Pacific


  12:40 PM

The ever-interesting Eric Lippert has a thoughtful post on how to create good error messages. His particular focus is on the error messages generated by a compiler, but there's very little in there, save perhaps the actual examples, that wouldn't apply to most situations.

His thesis in a nutshell is that error messages should be:
  • Polite
  • Readable
  • Accurate
  • Precise
  • Diagnostic but not prescriptive
... and I'll refer you to his post for the definitions and distinctions of these and for examples.

The last one, as he predicts, is probably the one that is likeliest to be debated by error message authors. The problem with being prescriptive, of course, is that you don't necessarily know what the user is doing, so it can be hard to tell them what to fix. For that matter, in many contexts you don't necessarily know what the problem is exactly; you might just know that something has gone awry. A classic example of this last is the error message you might sometimes see:

The type or namespace name 'some name' could not be found (are you missing a using directive or an assembly reference?)

I like this because it's diagnostic -- the message tells you exactly what the compiler doesn't recognize. But it's also ... well, not prescriptive, exactly, but, you know, helpful -- "People who see this message often see it because xxxx!" That is, it points you at what is probably the most common source of this error without telling you that that's your problem.[1]

Of course, no error message is any good if people don't read it at all. As Leon recently pointed out, those ASP.NET YSOD error messages have all sorts of useful information in them. When Eric and his team get done with revamping the C# compiler, they'll be even better ...


[1] Is it just me, or is that reference to the "using" directive C#-centric?

[categories]   , ,

[1] |