Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

To use error codes or not to use error codes

So, I've been working on a new project at work, and today had a coworker bring up the idea to me that my exceptions and even returned error messages should be completely localized. I thought maybe that was a good idea, but he said that I should only error return error codes. I personally don't like the error code idea a lot as it tends to make other programmers either

  1. To reuse error codes where they don't fit because they don't want to add another one
  2. They tend to use the wrong error codes as there can get to be so many defined.

So my question is what doe everyone else do to handle this situation? I'm open for all sorts of suggestions including those that think error codes are the way to go.

like image 810
Mike Avatar asked Feb 26 '23 14:02

Mike


2 Answers

There may be cultural differences, according to your coding language ?

In Java for example, numerical errors codes are not used much ...


Concerning exceptions, I believe it is just a technical tool. What is important is wether your message is targeted at a user, or a developper. For a user, localizing messages is important, if several languages appears, or to be able to change the messages without recompiling (to customize between clients, to adapt to changing user needs ..).


In my projects, our culture is to use (java) enums to handle all collections of fixed values. Errors are no different. Enums for errors could provide :

  • strong typing (you can't pass something else to a method that expect an error code)
  • simple localisation (a simple utility method can find automatically the message corresponding to each one, using for example "SimpleClassName"."INSTANCE_NAME" pattern ; you could also expose the getMessage() method on each enum, that delegates the implementation to your utility method)
  • verification of your localized files (your unit tests could loop for each language on the code and the files, and find all unmatched values)
  • error level functionnality (we use the same levels as for logging : fatal, error, warn ; the logging decisions are very easily implemented then !).
  • to allow for easy finding of the appropriate error by other developpers, we use several enums (possibly in the same package), classifying the errors according to their technical or functionnal domain.

To adress your two concerns :

  1. Adding one only requires adding an instance to an enum, and a message in the localisation file (but the tests can catch the later if forgotten).
  2. With the classification in several enums, and possibly the javadoc, they are guided to use the correct error.
like image 75
KLE Avatar answered Apr 07 '23 13:04

KLE


I wouldn't be using error codes for localization. There may be good reasons to use error codes (e.g. to be able to test which specific kind of error occurred), but localization is not one of those reasons. Instead, use the same framework that you use for the rest of the message localization also for exceptions. E.g. if you use gettext everywhere else, also use it in exceptions. That will make life easier for the translator.

like image 28
Martin v. Löwis Avatar answered Apr 07 '23 14:04

Martin v. Löwis