Fog Creek Software
Discussion Board

How do you maintain error numbers

I was just reading about how Fog Creek uses unique error numbers to help track down crashes in the field.  It got me wondering how you set and maintain those numbers.  How do ensure that they're unique?  What about concurrent development?

I had a project in the past where we tried to do that, but we frequently had problems with duplicate numbers.  People like to just copy and paste the chunks of code that process errors.  They'll paste the block, change the message to something appropriate and move on.

So, what happened is developers ended up ignoring the numbers and just searching the code for the matching message string.

For integration with FogBUGZ and automatic error reporting, it would be nice to just put a number in the bug title though.

David (
Tuesday, April 27, 2004

In the case of CityDesk the error numbers in question are just the COM/VB error code. That combined with the filename, line number, and version are enough to uniquely identify a particular crash and gather all the duplicates together under one bug.

Joel Spolsky
Fog Creek Software
Tuesday, April 27, 2004

May be you would like to take look at


Tuesday, April 27, 2004

Actually, that article is what led to my question.  Joel shows how they collect the error number, version number, etc. and use it for the bug title.  I was curious how he created and maintained those error numbers.  It's a problem I've run into in the past.

If anyone knows of a good, reliable way to manage this in C++, I'd love to hear it.

David (
Wednesday, April 28, 2004

For custom error numbers (in VB6, at least), I make a public Enum that contains all my custom error codes. If you then write a general HandleError() type of sub which takes one of those enums as an input parameter, it's easy to use VB's autocomplete to fill in the right blank.

What I want to know is: how do you get the (internal) line numbers for a COM object? Are these C++ objects (where I know you can use the __FILE__ and __LINE__ macros)? I've never found a VB equivalent, and would dearly like to find one...

Edmund Schweppe
Friday, April 30, 2004

VB has line numbers! It's Basic!

20 GOTO 10

Still works!

We have an automated routine that runs through the entire application and puts line numbers on every line. We do this right before shipping, check it in, tag it, and then strip off the line numbers again so we don't go crazy while developing.

Joel Spolsky
Fog Creek Software
Friday, April 30, 2004

Be nice if one day PC developers could get with the programme and do decent error reporting like MVS systems have been doing for, ooh, about 40 years.

Every type of error should have number that you can look up somewhere (even if it's an unhandled exception you can still give all those an Id e.g. "ERR001 Some strange shit happened" - followed by the exception details).

What else do MVS systems do? They give a letter indicating the severity (I-Informational,W-Warning,E-Error,S-Severe and C-Critical). You get a return code (0:ok, <=4:warning, >4:problem!) and you get a reason code (which may or may not be used - sometimes if an underlying component failed then the reason code will be used to store that component's return code).

MVS doesn't necessarily give you the location of the error but there used to be a big debugging handbook where you could look up error messages and it would tell you where they were issued.

What's really really cool is that for each error you could find out what it meant in real terms, and most importantly what you should do... fix something in the system, change a config file, report it to your administrator etc.

So, why do PC developers insist on producing crap error handling, especially Microsoft who give you the absolute bollocks "An error has occurred" AND THAT'S IT! I mean, WTF!

My own product gives each error it's own ID, return code, reason code, diagnostic info, remediation info and issuer. MVS standards on a PC. Quite a novelty.

This is implemented by an ErrorInfo class which then has a shit load of shared (in terms) methods; one for each error which requires specific parameters for that error and returns an instance of ErrorInfo with everything filled in.

An unhandled exception, for example, is then simply handled:

Catch ex as exception
  zErrors.Add ErrorInfo.CIM001C(ex)
End Try

It also adds each error into a collection as sometimes you may want to produce a chain of errors as an individual error may be inconclusive or misunderstood:

CIM017W : CI Name not supplied (etc...)
CIM201I : CI "" successfully created (ID=CIS:102)

Monday, May 3, 2004

> If anyone knows of a good, reliable way to manage this
> [error numbers] in C++, I'd love to hear it.

Search for
  Ken Raeburn,
  "A Common Error Description Library for UNIX".

Monday, May 3, 2004

on VC++ i find 'set_se_handler' function very useful.

With it you can convert a Windows Structured Exception into a C++ exception. This way you can get a C++ exception for say access violation and then use c++ try/catch mechanism to catch and log the error.

However, this will not give you filename and line no information

Nitin Bhide
Tuesday, May 4, 2004

Gwyn, do you just dump all that information in front of the user's face, or do you place that basic info in a "More Info" window similar to how I remember Microsoft doing back in the day (probably when Joel was working there).

Or, even better, do you go with a compromise and put the various error info in a text file or "More Info" style window and give some cleverly-written text based off the errnum to the dialog?

(And now to stop pretending I know what I'm talking about.)

Tuesday, May 4, 2004

The user gets a list of the errors (although they could be informational/warning so error isn't entirely the right word) showing just the message id and the description, e.g.

"CIM074E  Transaction Log query failed"

They then get a "Details >>" button which expands the form to include the detail fields and when they click on a message in the list it shows all the details for the selected error/message

Tuesday, May 4, 2004

"We have an automated routine that runs through the entire application and puts line numbers on every line. We do this right before shipping, check it in, tag it, and then strip off the line numbers again so we don't go crazy while developing."

You don't do GOTOs, right?

Leonardo Herrera
Monday, May 10, 2004


You don't do GOTOs, right?

I suspect Joel uses line numbers to enable use of Erl rather than Goto LineNumber.


Thursday, May 20, 2004

*  Recent Topics

*  Fog Creek Home