In one of the projects I’m working on the following pattern is seen on a fairly regular basis:
var guid = Guid.NewGuid().ToString();
while (guid == Guid.Empty.ToString())
{
guid = Guid.NewGuid().ToString();
}
While I understand that a a GUID is not guaranteed to be unique and as per the MSDN documentation a generated GUID may be zero, is this a practical consideration actually worth sending cycles testing for both in the computational sense and in terms of developer time thinking about it?
10
I would suggest it’s not worth checking for Guid.Empty. The docs for Guid.NewGuid for some reason mention that
The chance that the value of the new Guid will be all zeros or equal to any other Guid is very low.
Guid.NewGuid is a wrapper for the Win32 API CoCreateGuid, which makes no mention of returning all zeroes.
Raymond Chen goes further, suggesting that
no valid implementation of CoCreateGuid can generate GUID_NULL
So, no, I wouldn’t worry about it. I wont’ guess as to why the Guid.NewGuid docs even mention it.
8
If you find Guid.NewGuid() == Guid.Empty you have won the hardest lottery on earth. Don’t bother with any uniqueness or collision checking. Not having to do that is what guids are for. I will spare you the math, it’s everywhere on the web.
Also, Windows guids always have one “digit” equal to 4. There is some structure to guids.
That code snippet you posted looks like one dev forgot to initialize a Guid variable and found it to be Guid.Empty. He mistakenly identified Guid.NewGuid() as the cause. Now he will forever superstitiously believe in this.
In any case this is the wrong question to ask. I’m sure your code does not only depend on not ever drawing Guid.Empty but also on uniqueness. That while loop does not enforce uniqueness. Guids are there to produce a unique value without coordination. That is their use case.
2
Look at the source code of Guid.NewGuid method:
public static Guid NewGuid() {
Contract.Ensures(Contract.Result<Guid>() != Guid.Empty);
...
}
See the code contract? The Guid.NewGuid method never gives an empty GUID.
3
If you are going to check the GUID against the zero GUID, you by the same logic also need to do due diligence of checking it against all other GUIDs in your application (as the probability of getting a zero should be the same as the probability of getting any other GUID in your app*). You need to do this to prove the axiom you are acting under is that this GUID will be unique (which is actually the same axiom as testing vs 0).
Obviously doing this is absurd.
TLDR; If you can trust NewGuid() to produce unique results, you can also trust it to not produce any single known GUID.
* Its actually not the same probability as .NET GUIDs always fit the following {________-____-4___-____-____________} so NewGuid will NEVER generate a zero guid
Just for fun I suggested an improvement to the docs here: http://feedback.msdn.com/forums/257782-msdn-feature-suggestions/suggestions/7143498-fix-documentation-for-newguid
3
As of October 2023, the docs for Guid.NewGuid now state
The returned Guid is guaranteed to not equal Guid.Empty.
So there is no reason to check whether Guid.NewGuid returns an empty Guid.
During development, you might want to check, because there might be situations where a bug in your own code stores a null GUID where it shouldn’t.
After that: A GUID generator might guarantee never to create a null GUID. Or it might generate one randomly – the chance of that is less than one in a billion billion billion billions. In other words it will never happen. (In a galaxy far far away someone posted the same and was wrong).
If the GUID generator is so non-random that it generates empty GUIDs then it will produce so many conflicting GUIDs that you notice.
1