tags:

views:

442

answers:

16

Why did programmers ever start using status codes? I mean, I guess I could imagine this might be useful back in the days when a text string was an expensive resource. WAYYY back then. But even after we had megabytes of memory to work with, we continued to use them. What possible advantage could there be for obfuscating the meaning of an error message or status message behind a status code?

A: 

Make it easier for an end user to understand what is happening when things go wrong.

Aim Kai
+8  A: 

It's the same reason as ever. Numbers are cheap, strings are expensive, even in today's mega/gigabyte world.

spender
I don't agree, and don't think this is at all correct. Some of the other answers are more accurate, and it's do to with abstraction, machine readability and the advantages of static typing
andy
@andy: I'd say "partially correct" - e.g. "strings are expensive" is a part of "machine readability" IMHO: expensive to store, expensive to parse, expensive to handle encodings, the list goes ever on and on...
Piskvor
+3  A: 

Computers are still binary machines and numeric operations are still cheaper and faster than string operations.

Oded
+8  A: 

I don't think status codes constitute obfuscation; it's simply an abstraction of a state.

A great use of integer status codes is in a Finite-State Machine. Having the states be integers allow for an efficient switch statement to jump to the correct code.

Integers also allow for more efficient use of bandwidth, which is still a very important issue in mobile applications.

Yet another example of integer codes over strings is for comparison. If you have similar statuses grouped together (say status 10000-10999) performing range comparisons to know the type of status is a major win. Could you imaging doing string comparisons just to know if an error code is fatal or just a warning, eww.

Ben S
Range comparisons are anyway a kind of hack. A really nice error message must be an instance of a special class, so instead of checking the number to fit some range, one should call a virtual function.
Vlad
+24  A: 

It's easy to provide different translations of a status code. Having to look up a string to find the translation in another language is a little silly.

Besides, status codes are often used in code and typing:

var result = OpenFile(...);
if (result == "File not fond") {
    ...
}

Cannot be detected as a mistake by the compiler, where as,

var result = OpenFile(...);
if (result == FILE_NOT_FOND) {
    ...
}

Will be.

Dean Harding
The misspelling of "found" as "fond" is intentional, and doesn't need to be fixed. It's part of the explanation of why using a defined constant is more reliable than using a string.
Josh Townzen
Yeah, that's right...
Dean Harding
i bet that is just an excuse for that typo error :D
Gabriel
#define FILE_NOT_FOUND "File not found". There. Problem solved.
luiscubal
Haha, tuche :) but then how is `#define FILE_NOT_FOUND "File not found"` any different from `#define FILE_NOT_FOUND 2`?
Dean Harding
in C#, I envision one would create a public enum of message keys, which self-describe their use. Then, you could use "language plugins", or classes adhering to a public interface, which use that enum as the keys to a dictionary of strings in the specified language of the plugin. smart. Compiler verifiable, modular and configurable, and much easier for developers to read without doing tons of cross referencing.
David V McKay
+2  A: 

Well when talking to a customer over the telephone a Number is much better then a string, and string can be in many different languages a number can't, try googeling some error text in lets say Swedish and then try googling it in English guess where you get the best hit.

Petoj
+11  A: 

It allows for localization and changes to the text of an error message.

tomlogic
+2  A: 

Because not everyone speaks English. It's easier to translate error codes to multiple languages than to litter your code base with strings.

It's also easier for machines to understand codes as you can assign classes of errors to a range of numbers. E.g 1-10 are I/o issues, 11-20 are db, etc

Glen
+3  A: 

Integer representation in memory is a far more consistent thing than string representation. To begin with just think about all those null-terminated and Pascal strings. Than you can think of ASCII and the characters from 128 to 255 that were different according to different codepages and end up with Unicode characters and all of their little endian big endians, UTF-8 etc.

As it comes, returning an integer and having a separate resource stating how to interpret those integers is a far more universal approach.

Li0liQ
"Integer representation in memory is a far more consistent thing than string representation." - True dat. Though I should point out endianness problems, and the discrepancy of sizes of ints across architectures.
amphetamachine
Not if you're writing Java.
duffymo
@duffymo Java is not the only programming language out there, sometimes even it needs communicating with other languages ;)
Li0liQ
Agreed, but the endian and size problems that amphetamachine brought up aren't an issue.
duffymo
The thing about status codes that really bugs me is that they don't mean anything by themselves. You have to cross reference them with your string tables. Some other guys here had a good point - why use CODES at all, when you can use IDENTIFIERS. Using programmatic structures rather than embedded literals allows for static verification, without disallowing globalization, and I bet most compilers are very efficient at handling identifiers. It is no longer a string operation, but instead a memory addressing operation.
David V McKay
+4  A: 

404 is universal on the web. If there were no status codes, imagine if every different piece of server software had its own error string?

  • "File not found"
  • "No file exists"
  • "Couldn't access file"
  • "Error presenting file to user"
  • "Rendering of file failed"
  • "Could not send file to client"
  • etc...

Even when we disregard data length, it's still better to have standard numeric representations that are universally understood, even when accompanied by actual error messages.

Chris
that's not a valid comparison. If people can disagree on different status strings, they can disagree on status codes too, after all. Error codes are better than strings because they're more concise.
Adriano Varoli Piazza
Directily from RFC 2616: "The individual values of the numeric status codes defined for HTTP/1.1, and an example set of corresponding Reason-Phrase's, are presented below. The reason phrases listed here are only recommendations -- they MAY be replaced by local equivalents without affecting the protocol."The status codes are absolutely defined in the spec, while the string representations are left to the implementation.
Chris
Right, but Adriano's point is that the designers of HTTP could've easily have standardized around an error string instead of a number, i.e., instead of deciding 404 means "not found" and the phrase doesn't matter, they could've decided that "Not Found" *is* the error code.
mipadi
Or, conversely, that Microsoft (let's just say, I don't really know if they had any web server working before everything was standardized), instead of using 404 as not found could have chosen code 314, because they thought so first.
Adriano Varoli Piazza
@Chris: I actually worked with a server that returned "302 Found someone you have." as a HTTP response.
Piskvor
+7  A: 

Numbers can be easily compared, including by another program (e.g. was there a failure). Human readable strings cannot.

Consider some of the things you might include in a string comparison, and sometimes might not:

  • Encoding options
  • Range of supported characters (compare ASCII and Unicode)
  • Case Sensitivity
  • Accent Sensitivity
  • Accent encoding (decomposed or composed unicode forms).

And that is before allowing for the majority of humans who don't speak English.

Richard
If we are only concerned about equivalence of the strings, then a binary byte-for-byte comparison ought to be sufficient, and completely independent of encodings.
David V McKay
@David: that is true, if strings are not localised. But if they are not localised then what advantage to they offer over status codes? (Most people do not speak English... and when I say English I mean English where colour is spelt correctly :-).)
Richard
+2  A: 

Status codes are unique, whereas strings may be not. There is just one status code for example "213", but there may be many interpretation of for example "file not found", like "File not found", "File not found!", "Datei nicht gefunden", "File does not exist"....

Thus, status codes keep the information as simple as possible!

Marcel
+2  A: 

How about backwards compatibility with 30+ years of software libraries? After all, some code is still written in C ...

Also ... having megabytes of memory available is no justification for using them. And that's assuming you're not programming an embedded device.

And ... it's just pointless busy work for the CPU. If a computer is blindingly fast at processing strings, imagine the speed boost from efficient coding techniques.

Duncan
+1 for 2nd and 3rd paragraph. This is something a lot "developers" forget.
poke
+2  A: 

I work on mainframes, and there it's common for applications to have every message prepended by a code (usually 3-4 letters by product, 4-5 numbers by specific message, and then a letter indicating severity of the message). And I wish this would be a standard practice on PC too.

There are several advantages aside from translation (as mentioned by others) to this:

  1. It's easy to find the message in the manual; usually, the software are accompanied with the message manual explaining all the messages (and possible solution, etc.).

  2. It's possible for automation software to react in the specific messages in the log in a specific way.

  3. It's easy to find the source of the message in the source code. You can have further error codes per specific message; in that case, this is again helpful in debugging.

J S
+2  A: 

For all practical purposes numbers are the best representation for statuses, even today, and I imagine would be so for a while.

The most important thing about status codes is probably conciseness and acceptance. Two different systems can talk to each other all they want using numbers but if they don't agree on what the numbers mean, it's going to be a mess. Conciseness is another important aspect as the status code must not be more verbose than the meaning it's trying to convey. The world might agree on using

The resource that you asked for in the HTTP request does not exist on this server

as a status code in lieu of 404, but that's just plain nuisance.

So why do we still use numbers, specifically the English numerals? Because that is the most concise form of representation today and all computers are built upon these.

There might come a day when we start using images, or even videos, or something totally unimaginable for representing status codes in a highly abstracted form, but we are not there yet. Not even for strings.

Anurag
You make some very good points. Surely your example of a replacement for '404' would be a nuissance - it takes forever to visually parse. I especially like the idea of using images or something more abstract rather than integers. I think our toolsets may allow us to annotate status codes with their meanings too, so as to solve my real beef with error codes (the need to do extra work to cross ref their meanings). What we may have here is the initial learning curve efficiency versus familiar usage efficiency problem.
David V McKay
A: 

It helps to have a very basic method of giving statuses clearly and universally. Whereas strings can easily be typed differently depending on dialect and can also have grammatical changes, Numerals do not have grammatical formatting and do not change with dialect. There is also the storage and transfer issue, a string is larger and thus takes longer to transfer over a network and store (even if it is a few thousandths of a millisecond). Because of this, we can assign numbers as universal identifiers for statuses, for they can transfer quicker and are more punctual, and for the programmes that read them can identify them however they wish (Being multilingual).

Plus, it is easier to read computationally:

switch($status) {
case '404':
echo 'File not found!';
break;
case '500':
echo 'Broken server!';
break;
}

etc.

JonnyLitt