1

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?

Improve this question
6
  • 4
    How about using a Guid?
    – MikeSW
    Commented Feb 8, 2014 at 9:00
  • 3
    What? Even the db has the Guid data type aka UUID. Why do you want integers? And I'm using Guids on windows a lot btw, it has nothing to do with unix. THe time thing is how they are generated but you care about the outcome which is always the same size 16 bytes I think.
    – MikeSW
    Commented Feb 8, 2014 at 10:13
  • 7
    Wow, I can imagine a few reasons to only develop for 64 bit servers. The need to have unique error numbers is not one of them.
    – Pieter B
    Commented Feb 9, 2014 at 0:01
  • Trying to encode intelligence into what is essentially a one-up sequence number is bad news. If you absolutely have to have global uniqueness, hand individual error numbers or blocks of them out to your projects as they need them.
    – Blrfl
    Commented Feb 9, 2014 at 0:14
  • 4
    What happens when Mike Smith and Mary Simpson join the team?
    – Kramii
    Commented Feb 12, 2014 at 6:40

8 Answers 8

Reset to default
17

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.

Improve this answer
2
  • Would you also argue that striving to create unique error numbers is a bad idea (making it less of a hard and strict specification)? I don't really see how it can hurt, but I do see many tangible upsides.
    – DudeOnRock
    Commented Feb 8, 2014 at 22:34
  • 4
    @DudeOnRock: error numbers are no end in itself, making them unique must have a purpose. So think about what you want to accomplish, and how much "uniqueness" you will need really to reach that goal. If you just want those error numbers for easier unit testing, you need them only to be unique in the local scope of that unit test, and typically not across project boundaries.
    – Doc Brown
    Commented Feb 8, 2014 at 23:41
11

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.

Improve this answer
2
  • Great point about efficiency. In response to you premature optimization worries: I started thinking about creating unique error numbers because the current way I check if the correct exception is thrown in a unit test is more work than remembering a simple algorithm that will create a unique error code with high certainty. Therefore it would actually make my life easier.
    – DudeOnRock
    Commented Feb 8, 2014 at 22:38
  • I think I would have looked for other ways to make unit testing easier. What you have here is unit testing driving the design of the application, which seems a bit "wrong" to me. (I'm not a PHP developer, and I don't know if there is a better way to unit test for exceptions. But if not, that would seem to be a shortcoming of the unit testing framework you are using ...)
    – Stephen C
    Commented Feb 9, 2014 at 1:20
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.

Improve this answer
2
  • I guess it would have been helpful to mention that I am using PHP. In php it appears I can not use non-integers as error numbers for exceptions. In regards to your concern, if I understand it correctly: The error code is hardcoded. It is accompanied by an error message. The nice thing about unique error codes is, that it is possible to determine the exact line of code that threw an exception, which is extremely beneficial when trying to distinguish between exceptions that have the same message but have different origins.
    – DudeOnRock
    Commented Feb 8, 2014 at 9:40
  • Even with 32 bit integer codes one can have several million unique values. The design can block off ranges for errors of a common type and and when a new specific error is needed then it can be spec'd out and used.
    – BPugh
    Commented Feb 8, 2014 at 9:56
3

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?

Improve this answer
2

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.

Improve this answer
0

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.

Improve this answer
0

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.

Improve this answer
0
0

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?

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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