6

I'm designing a backend webservice, and when an error occurs I'm returning it as a JSON to the frontend. This JSON contains an error code, which the frontend maps to an localized string and shows that to the user.

Should my error codes be strings or integers?

{
  "error": {
    "code": 9900,
    "message": "Invalid ID"
  }
}

OR

{
  "error": {
    "code": "9900",
    "message": "Invalid ID"
  }
}

I'm thinking integers myself, but I'm just wondering if maybe returning fixed length error codes would be more correct, like if I atm have error codes like 9900, 9901, and in the future I wanna send the code 12, would it be correct to send them as "9900", "9901", and "0012", vs 9900, 9901, and 12.

  • Any particular reason you're thinking of for returning a string or? – Milan Velebit Aug 7 at 7:45
  • 2
    @MilanVelebit Just wondering if maybe returning fixed length error codes would be more correct, like if I atm have error codes like 9900, 9901, and in the future I wanna send the code 12, would it be correct to send them as "9900", "9901", and "0012", vs 9900, 9901, and 12. – ruohola Aug 7 at 7:51
  • No, I was just wondering whether there was a special reason for returning a number as a string. If none, I'd personally just use a plain number. – Milan Velebit Aug 7 at 8:03
  • Just want to note that the question is based on very flawed premises: neither is more or less "correct". There is no one true answer. There only is: fits my needs today? and fits my likely needs tomorrow? If you can tick both for all your options, toss a coin if you don't want to decide yourself. – marstato Aug 7 at 18:29
  • 2
    @marstato Right, error codes are ids. They are not quantities. You can't do math on them. The only real advantage of using integer is storage and for JSON that's pretty much irrelevant. Ultimately, even if you store them as integers, they should be treated like strings. – JimmyJames Aug 8 at 15:19
5

I would go with text. It's OK to have a string where you only use numbers. As a rule of thumb: you should not use integers for things that are not mathematical in nature. That is, if you can do addition or multiplication on the values in a sensible way, then it's a number. Otherwise it's an identifier and you should stick with text. In practice you will probably be fine but using integer types to hold things that are not really numbers can end up being a problem. A classic example is using an integer to store zip-codes i.e. US postal codes.

  • So what if the error string is "abcde"? Is that a valid error string or an error? (Errors in error reporting are usually fatal). Are "12" and "0012" the same or different errors? If they are the same, you can't just compare them as strings, you have to convert them to integers, so why not send them as integers in the first place? – gnasher729 Aug 7 at 18:33
  • 3
    @gnasher729 "Are "12" and "0012" the same or different errors?" Different. Whatever system you are using, you should be consistent. There's no reason to convert your error codes to integers for the same reason you shouldn't represent them as integers. They don't represent quantities. They are strings that may or may not contain only digits. – JimmyJames Aug 7 at 19:31
3

I'd suggest to a static constant string to both be able to map to i18n and keep expressiveness.

Something like this is nice:

{
 error: 'invalid_id'
}

And you can even scope it to module to locate the origin of the error and avoid overlapping:

{
 error: 'auth.invalid_id'
}

Or, you could also add the http response code inside the object, but that's redundant with the response itself, but might be useful in some case you want to be independent of HTTP and maybe use other type of communication but still use the semantic of it.

{
 error: {
   key: 'auth.invalid_id',
   http_code: 401
 }
}
2

Do you need to do math on it? if errorCode>9000 etc
Do you need to pass it into anything that expects an integer?
Do you want an early error if you accidentally type an x in the code value?

If you answered no to all of these I can't see a reason why not to use strings.

As for your comment about 0012 vs 12, that's a presentation issue. The backend shouldn't care which you do. But it does presume 9999 is your biggest error code.

  • You can still do greater than and less than on alphanumeric values. – JimmyJames Aug 7 at 18:19
  • @JimmyJames: 1, 10, 11, 12 ... 18, 19, 2, 20, 21... – Robert Harvey Aug 7 at 18:27
  • @RobertHarvey '01', '02', '10', '11', '12' ... '19', '20', '21' – JimmyJames Aug 7 at 18:28
  • @JimmyJames: Well, yeah. But you're making an assumption the OP didn't make (yet). – Robert Harvey Aug 7 at 18:29
  • @RobertHarvey In the second comment on the question the OP mentions using code "0012" instead of 12. – JimmyJames Aug 7 at 19:24
1

Nobody has brought this up but numbers are usually better for i18n. The client can decide what text to display. In many cases the client will have to translate the text depending on the locale, so in most cases this is easily done on the client as there are mechanisms to handle internationalization.

@Bellon's answer also sends the text as well for troubleshooting purposes as someone who is not familiar with number codes can see what the error is.

0

If you want to send integers, send them as integers. If you have an error code “abcde” then send strings. If “12” and “0012” are different error codes then send strings. But if you the receiver wants integers, send integers.

  • While technically this is true, it would be a horrible design, to have "0012" and "12" as two different error cases. It's pretty much guaranteed, that someone will confuse the two. – Noceo Aug 8 at 19:08
  • You’re absolutely right. So send integers. – gnasher729 Aug 9 at 21:04
0
{
    "code": 9900,
    "message": "Invalid ID"
}

Should be the most appropriate. The standard for numbers requires not to have quotes.

https://www.json.org/

http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf

Personally, I'd suggest to follow a pattern for code values similar to the one used by HTTP, so grouping categories of errors (not necessarily grouped by hundreds, but maybe by tens)

  • "The standard for numbers requires not to have quotes." -- Not sure I follow. "9900" is a valid JSON string. The question is if the value should be a number or a string, not what the JSON standard is about. – Captain Man Aug 9 at 13:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.