On the surface it seems string values would be an improvement but that clearly doesn't scale well.
Why not?
AFAIK most languages with exceptions accept a string message in their constructor, so you can get typed errors with meaningful messages. In fact, I make a point to call out in code reviews where someone throws an exception but gives no indication of the state the code was in that threw the exception.
For example: it's one thing to throw a JSONParseException, it's another to point out where (line & column) it happened!
String messages are great to inform the developer about what went wrong, but are not that great to handle errors programmatically. In Java, you use exception classes to decide how a given error is going to be handled. Therefore, you don't need error codes to identify the type of error because the exception class does that job.
However, error classes are a luxury that you don't always have. Imagine that you are sending errors over a network. If you only send error messages, the code at the other side of the network might have a hard time deciding how to handle any given error, while error codes make the discrimination much easier.
Really I was thinking of the Error or Exception itself. You might have an exception with a name and numeric id that could be thrown from many different places. Each time it's thrown could require a different message. I think it's mostly poor implementation I'm seeing. As pointed out, there are decent ways to deal with this, implementors just need to use them.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Why not?
AFAIK most languages with exceptions accept a string message in their constructor, so you can get typed errors with meaningful messages. In fact, I make a point to call out in code reviews where someone throws an exception but gives no indication of the state the code was in that threw the exception.
For example: it's one thing to throw a JSONParseException, it's another to point out where (line & column) it happened!
String messages are great to inform the developer about what went wrong, but are not that great to handle errors programmatically. In Java, you use exception classes to decide how a given error is going to be handled. Therefore, you don't need error codes to identify the type of error because the exception class does that job.
However, error classes are a luxury that you don't always have. Imagine that you are sending errors over a network. If you only send error messages, the code at the other side of the network might have a hard time deciding how to handle any given error, while error codes make the discrimination much easier.
Really I was thinking of the Error or Exception itself. You might have an exception with a name and numeric id that could be thrown from many different places. Each time it's thrown could require a different message. I think it's mostly poor implementation I'm seeing. As pointed out, there are decent ways to deal with this, implementors just need to use them.