29

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?

Improve this question
9
  • 3
    If you are seeing this pattern repeatedly perhaps a utility method would be in order? Repeating code chunks like this seems like a bigger problem than the fact that you are checking an edge case that will never happen and might not matter even if it did happen. Commented Feb 25, 2015 at 21:37
  • 35
    That code is there to keep the alligators away. Are there alligators where you write code? No? Then obviously it works! Commented Feb 25, 2015 at 22:54
  • 6
    Whatever the case, I would do this in a do-while. Commented Feb 26, 2015 at 2:09
  • 5
    Why on earth are you converting the guids to strings and then comparing? they compare fine on their own. Commented Mar 2, 2015 at 23:56
  • 5
    The documentation had been updated: "The returned Guid is guaranteed to not equal Guid.Empty." Commented Nov 12, 2015 at 10:35

6 Answers 6

Reset to default
35

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 Co­Create­Guid 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.

Improve this answer
9
  • 1
    "And even if it did generate GUID_NULL for some reason, uniqueness would require that it do so only once! (So you should try to force this bug to occur in test, and then you can be confident that it will never occur in production.)" - Nice! Commented Feb 25, 2015 at 20:10
  • 4
    @razethestray - You can bet all you want at my casino. Commented Feb 25, 2015 at 20:14
  • 10
    @JeffO Jokes on you, he made sure to spin 37 times at home and is going to put all his money on the one that didn't come up. Commented Feb 25, 2015 at 22:16
  • On xamarin, Guid.NewGuid fails sometimes and returns empty constantly(when guid is assigned automatically in ef core) haven't been able to figure out why Commented Apr 22, 2019 at 5:12
  • 1
    @CurtNichols if i reported every bug i got in xamarin, i wouldn't ever get any work done lol. also ef core team has said xamarin compatibility isn't a focus for them so any bugs reported get assigned to "some day". if you saw how migrations need to be done currently you'd laugh Commented Apr 23, 2019 at 6:30
46

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.

Improve this answer
2
  • 5
    +1 to "wrong question to ask". It's all about uniqueness, that's all that really matters. Commented Feb 25, 2015 at 22:48
  • 1
    @rjzii consider making this the accepted answer! Commented Feb 27, 2015 at 9:15
21

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.

Improve this answer
3
  • 2
    Not sure why you received a downvote, since it mentions something which is missing in other answers. The presence of the code contract is a pretty good guarantee, and also gives an excellent answer to the original question. +1 for the idea of looking at the actual implementation. Commented Mar 2, 2015 at 20:32
  • I love code contracts. Commented Mar 2, 2015 at 23:59
  • I'm quite sure that method is not available on iOS, so it's rather pointless. Commented Nov 28, 2022 at 9:34
10

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

Improve this answer
3
  • 3
    Why do .NET GUIDs always include a 4? Commented Feb 26, 2015 at 2:19
  • 11
    @ArturoTorresSánchez: For the answer to your question and many more fun facts about GUIDs, see my series of articles which begins here. ericlippert.com/2012/04/24/guid-guide-part-one I note that Luke already linked to part three for your convenience. Short answer: Version 4 GUIDs always include a 4. Commented Feb 26, 2015 at 2:34
  • @EricLippert its a very good article :) Commented Feb 26, 2015 at 3:00
1

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.

Improve this answer
-1

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.

Improve this answer
1
  • 1
    Per another answer the contract ensures that null will not be returned. Commented Nov 28, 2022 at 18:07

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.