CODEWITHSUNDEEP
javaerror-handlingenterprise
zx_wing
zx_wing

Reputation: 1966

define error code, number or string?

When I use enterprise application, I am usually greeted by some error that needs to consult help desk. I found many application still lean to use number as error code instead of a human readable string. Given most enterprise applications are written in modern language like java/C#, I can not figure out what's the benefit in using numeric error code.

So the question is, for enterprise application, is there a common adopted pattern for defining error code? is any reason number preferred to string?

BTW: I understand application using REST API likely use http status code for error code, this is understood as http status code itself is number. but for others, I don't understand

Upvotes: 5

Views: 3208

Answers (5)

Kishor Neupane
Kishor Neupane

Reputation: 128

To me the better approach would be to do something like this, have a numeric-error code and then a string-based error code. The numeric error code should never repeat itself.

Something like this:

[
    'success': false,
    'statusCode': 404,
    'errorCode': 1001001,
    'errorLabel': 'invalid_endpoint'
]

This would be a way I would use. HTTP Response code are a must, and so are errorCode as they exactly define what kind of problem you're facing. Generally thrown by an exception and shows what you need to do to solve the problem.

Then, I would also incorporate the errorLabel (also the same errorCode but in string form). This would then allow me to find exactly what has happened if I know somewhat about the program.

The errorLabel or string errorCode would allow me to identify the errorCode without referring to the documentation.

So, the best method would be to incorporate the if you want to design a better system.

Let me show one example of what I have done in my projects.

[
    'success': false,
    'statusCode': 500,
    'errorCode': 5004003,
    'errorLabel': 'registration.invalid_source'
]

This way, I can make string based erorrCode and it allows me to read faster. The main thing is to make sure that you never repeat the numeric code but errorLabel is permitted though not in the same scope of code.

Upvotes: 0

PhoenixPan
PhoenixPan

Reputation: 551

Use number.

I didn't see a real answer here...There are many sources that suggest you should always use numeric values, one example: https://www.w3.org/Protocols/HTTP/HTRESP.html

Upvotes: -1

Tomasz Bekas
Tomasz Bekas

Reputation: 686

I had recently similar problem and I have decided to use following rules:

  • Similar errors are grouped in types (in Java these would be Exception Classes)
  • Each error has enumerated value that identifies it (that is an error code)
  • Each error has human readable message
  • Errors optionally can have a cause (in many situations your errors were generated because some other error occurred, and that error is a cause)

You could argue about the need of the second rule since you could have as many types as possible errors. However if your system is growing, sooner or later you will find the need of introducing new types of errors, which will entail modification of your API and that's not always possible and even if it is, it might be not very easy since you will have to modify all of your clients. Enumerated error code list is simply easier to maintain in that case.

Upvotes: 0

keshlam
keshlam

Reputation: 8058

The single greatest benefit of error codes -- along with more informative strings -- is that they can be looked up even after your code has been translated into another language which you may not read.

The next greatest benefit is that if someone ever writes code that reads your error messages -- perhaps your own company, to help folks manage your appliction -- it is tremendously helpful for them to have an error code at the start of the message. That both speeds up their decision of what to do, and partially guards them against the risk that you might rephrase the message later (which would mess up attempts to search for the message text).

Any convention can work if you reliably stick with it. If you're thinking about the long term and multiple products, you'll probably want the code to include some indication of which code (application and/or library and/or other module) issued the error, and then you want to be able to quickly find the error in that product's support table.

IBM usually uses a moderately recognizable alphabetic prefix to identify the code, and a numeric suffix to indicate the specific message. Other companies probably do it differently.

Upvotes: 2

Dave Newton
Dave Newton

Reputation: 160191

It's usually convenient to have both, a code, numeric or otherwise, and something human-readable.

The code makes it easy for machines to know what happened (and serve as shorthand for humans), and is verbiage- and locale- independent.

Upvotes: 3

Related Questions