I'm about to implement Error codes for my company API, so, based on rfc7807 I will include a type which is an error type which is basically an error category, and inside those categories we have a bunch of error codes, so, I'm stuck thinking/searching what's the best approach to follow, I mean, if i handle these error categories/codes in database, I'll need to define an enum with the codes to lookup in database their descriptions..

So this doesn't sound maintainable, because although the codes are in DB and it doesn't depends on the application server to deploy, everytime i define an error code or category in database i'll need to define it in the enum which sucks.

but seems like there's no other way to handle it, thing is, i need this error handling to work in several distributed units (microservices, some monoliths, etc) so what could be a good approach ?


Error Code != Enum

Your Error Code is not an enumeration, it is its own object.

Enumeration (and constants in general) are great ways to encode the initialisation value of an Error Code.

They are horrible as the storage unit itself. Because as you point out a receiver defining the error code as an enumeration dictates what are "legal" error codes, even though it has the least information about it.

Identity, Category, and Semantics

So what do you mean when you say Error Code?

  • Is it a unique identifier that describes one very specific failure state?
  • Is it a categorical identifier that describes a class of failures?
  • Is it an instruction that describes how the receiver of the error should respond?
  • Or some combination of the above?

The only place that knows the error code, is the place that generates it. (Hopefully corroborated by judicious unit tests.)

Everywhere else, be it in the same application or afar, does not care about the exact value. What they care about are capabilities (serialisation) and questions (network issue?, can I try again?).


The other issue you have hit upon is that you are distributing the same responsibility across several actors.

This is no different to any other kind of message passed between systems. I recommend defining the protocol of each interface. Each system that works through that interface has to map to and from that protocol in whatever way makes sense.

This is painful, but they are separate pieces of software. Increasing the coupling between them by forcing a shared notion of error code (aside from what is defined in the interface protocol between them) makes both pieces of software more brittle.

Brittle - not just because they must use the same version of the library - but because they must synchronise appropriate uses of unique identifying error codes, and fully agreeing to the categories and semantics of error codes in general.

You could ameliorate the brittleness by insisting on backward compatibility, but that is its own cage of snakes.

  • Actually I'm not following you, I mean, I didn't say I was going to use an Enumeration as the source of the error codes, I said, I was going to store them in database, and I was going to use an Enumeration to put the error keys so i can get the category, descripton etc from the database... – Ricardo Oct 30 '19 at 17:08
  • @Ricardo okay, that wasn't quite clear from your question. You mention multiple services for which this is to work across, and that there is a DB and an enum - no mention of an error object or class. Perhaps you should consider writing a script to auto generate the file containing the enum. eg: build the db, run the extract script and replace the enum containing file, then compile the binary. – Kain0_0 Oct 30 '19 at 22:30

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.