Using error numbers which only work on 64 bit servers: a bad idea?

Question

In an attempt to solve one problem I encountered another. I would like to have an easy and memorable way of creating unique error numbers, across projects and across developers. The scheme I came up with was to use the initials of the developer, find their position in the alphabet, and append the date and time. Example: lets say the developer Mark Elliot Zuckerberg (initials MEZ) writes code that throws an exception on Feb 8th 2014 at 12:54AM. The error code would be: 8526020820140054

This works brilliantly on 64 bit machines, but the resulting integer is too large for 32 bit computers. Does that make this a bad idea? How common are 32 bit servers, and do we expect them to slowly disappear completely?

Answer 1

I would like to have a [...] way of creating unique error numbers, across projects and across developers.

IMHO that is the bad idea. You should avoid the need for having a global unique error number across project boundaries. That is a global requirement you cannot fulfill as soon as you need to add third-party components, and at the long run, it will also be hard to enforce such a rule across many projects and many developers. So better design your system in a way you can manage your error numbers locally, this will give you much more flexibility and does not couple unrelated projects together with obstructive rules.

How your indivual projects manage their error numbers then is up to them, but I am pretty sure they will find a way to keep them below 32 bits.

Answer 2

This works brilliantly on 64 bit machines, but the resulting integer is too large for 32 bit computers.

Actually, 32 bit computers can handle 64 bit numbers just fine. OK, so 64 bit arithmetic might take a few extra clock cycles on a 32 bit machine, but this is unlikely to be significant. (Or even relevant ... in your use-case.) For instance, the x86 instruction sets have 64 bit arithmetic instructions.

Does that make this a bad idea?

Not for the reason you stated. It could be a bad idea for other reasons. (For instance, if there is more information that you can encode in 64 bits then your scheme breaks down.)

How common are 32 bit servers, and do we expect them to slowly disappear completely?

They are still common, and they are likely to continue indefinitely. If you don't actually need more than 2^30 of address space for an application, then 32 bit pointers occupy less memory than 64 bit pointers ... so a "small" model architecture is going to be more power efficient, etc.

---

I also agree with @DocBrown. Error numbers introduce all sorts of problems of their own ... including the tendency to display unintelligible sequences of digits to end users. The human friendly approach is a well named exception, and an intelligible / informative exception message.

---

The other observation is that your question shows the signs of "premature optimization". The chances are that the real impact on performance of your proposed optimization will be insignificant, and possibly even too small to measure in a real application running under realistic conditions.

The standard advice is to not waste your time on this kind of thing ... unless you have concrete evidence (from measuring your application) that 1) the effort of optimization is warranted, and 2) this particular bit of code has a significant impact on your application's overall performance.

Answer 3

Why not use a string data type for the error code instead of a number? This will allow large code to be stored without any issues as to integer size. Even though the error code does look like a number, unless the design is calling for arithmetic with it then it is not a number, then it really should be a string data type.

I'm also a little concerned about this method for error codes. Error codes should be designed into the application, listed in the documentation, and when triggered be predictable. If your code triggers an exception then it should be the same error code with the same inputs. However this design is using a random event to identify the error, nor does it point where in the code that the exception is happening, only who wrote the code and when the exception was fired.

Answer 4

This is a very bad idea.

You want "Easy and memorable". You've already discovered that your solution isn't easy.

1. You're considering backing yourself into a 64-bit corner to solve this problem.
2. What happens when Mary Smith and Mike Simpson join the team?
3. How can you guarantee uniqueness of the numeric part?
4. Whenever you rely on programmer memory, you place additional cognitive burden on your programmers. That will either be a distraction from coding, or will get forgotten
5. You're re-inventing the wheel. GUIDs already exist, and can be converted to 128-bit integers.
6. 32-bit machines can handle 64-bit numbers perfectly happily.
7. 3rd party libraries won't follow your scheme.

Are you solving the right problem? What is the benefit of unique error numbers? How important is this requirement to your clients?

Answer 5

If you must really go that way (sometimes it's a requirement imposed by the "up-aboves").

you could create long explicit String codes ie : ERROR__PROJECT_COULD_NOT_CREATE_THAT_UBER_IMPORTANT_RESOURCE

and through a deterministic hashing function turn it into a 32 bit integer.

Ideally to be global you should probably have some sort of centralized repository where one could enter the string code and get the hash for it. That same repository could also generate code to include in your project so the code can then refer to the string constant rather than that ugly magic number. Being centrally generated all projects would include the same lib/header and get the codes. Also the repository would be able to warn of possible (as unlikely as may be) of hash collision.

Mind you I don't think this is the best solution, I whole heatedly agree with Doc Brown here and take a step back towards this whole requirement. Just that it would make it not hurt as much to be stuck in this situation.

Answer 6

Let a database create your unique number for you -- log the error to a sql db, and your problem is solved. Include application info (ie what app encountered the error) and Bob's your uncle.

Answer 7

My advice is to migrate your code to 64 bit OS and processors. When you are purchasing new PC, Laptop or server go for 64bit. Currently Microsoft doesn't have the Server edition with 32bit, it only have 64bit Windows server 2008 and 2012.

Reason behind is 19 January 2038 32 bit computers date will be resets to 1 January 1970, please refer the below link.

http://en.wikipedia.org/wiki/Year_2038_problem

If your application does loan interest processing on Jan 13 2038, your 32bit computer automatically reset the date to Jan 1970 and company might have a chance to pay interest to customers.

Again, you will have a question when 34 bit OS date will reset. It will take some billion years to reset.

Answer 8

Two issues here:
1) "unique error codes across products. BAD idea as others have already indicated
2) "32 bit servers. Do those even still exist? And if so, do you really think the people operating them are going to want to pay for your product if they've not seen fit to upgrade their hardware and operating systems in the last several years?