null Guid

[Peter K]

Hi - should the following compile? I ask because a Guid is a struct and can
never be null... The worst the compiler throws at me is an "unreachable
code" warning.

public string GetData(Guid id)
{
if (id == null)
throw new ArgumentNotNullException("");

string s = null;

// do stuff...

return s;
}
Thanks,
/Peter

[Jon Skeet [C# MVP]]

On Aug 8, 2:08 pm, Peter K <[e-mail]:

Hi - should the following compile? I ask because a Guid is a struct and can
never be null... The worst the compiler throws at me is an "unreachable
code" warning.

Yes, it should compile - at least in C# 2. It's actually effectively
doing this:

if ((Guid?)id == null)

Unfortunate, but that's the way the lifted operators for nullable
types work.

Jon

[madhatter2647]

Acutally, in 2.0, you can declare nullable types as such:

Nullable<Guidg = null;
Nullable<boolb = null;

This way you can be sure the code will work.

[Jon Skeet [C# MVP]]

On Aug 8, 2:48 pm, "[e-mail]" <[e-mail]>
wrote:

Acutally, in 2.0, you can declare nullable types as such:

Nullable<Guidg = null;
Nullable<boolb = null;

This way you can be sure the code will work.

The point is that the OP doesn't *want* a nullable GUID - he's just
surprised that you can compare a value type with null, which is quite
a reasonable thing to be surprised about.

(Personally I prefer the C# syntax for nullables - Guid? instead of
Nullable<Guidetc.)

Jon

[Nicholas Paldino [.NET/C# MVP]]

Peter,

Two things. First, as Jon mentioned, the code will compile. However,
whether or not it will run correctly is another story. As the compiler has
pointed out to you, the code that throws the exception will never be
reached. This is a warning (which the compiler does not emit in C# 3.0),
and if you have the "treat warnings as errors" flag set in your project, it
will not compile.

The reason, of course, is because the id parameter can never be null,
since Guid is the type (which is a value type) and it is not nullable.

Now, at runtime, you are going to have a problem further up in the call
stack if you try and pass null.

The second thing is that there is actually a "null guid" which is a guid
with all zeros for values.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Peter K" <xd****@hotmail.comwrote in message
news:e%***************@TK2MSFTNGP02.phx.gbl...

Hi - should the following compile? I ask because a Guid is a struct and
can
never be null... The worst the compiler throws at me is an "unreachable
code" warning.

public string GetData(Guid id)
{
if (id == null)
throw new ArgumentNotNullException("");

string s = null;

// do stuff...

return s;
}
Thanks,
/Peter

[Jon Skeet [C# MVP]]

On Aug 8, 3:20 pm, "Nicholas Paldino [.NET/C# MVP]"
<[e-mail]:

Two things. First, as Jon mentioned, the code will compile. However,
whether or not it will run correctly is another story. As the compiler has
pointed out to you, the code that throws the exception will never be
reached. This is a warning (which the compiler does not emit in C# 3.0),
and if you have the "treat warnings as errors" flag set in your project, it
will not compile.

The reason, of course, is because the id parameter can never be null,
since Guid is the type (which is a value type) and it is not nullable.

Agreed.

Now, at runtime, you are going to have a problem further up in the call
stack if you try and pass null.

No, that error will occur at compile time instead.

The second thing is that there is actually a "null guid" which is a guid
with all zeros for values.

I think it's clearer to call that the "empty" GUID because:
1) It's available using Guid.Empty
2) It allows you to talk about a null Guid? vs a Guid? with a value of
Guid.Empty

Jon

[Nicholas Paldino [.NET/C# MVP]]

Jon,

> Now, at runtime, you are going to have a problem further up in the
call
stack if you try and pass null.

No, that error will occur at compile time instead.

If you pass null directly to the method, yes, it will occur at compile
time, but I was thinking of this case:

object o = null;

string s = GetData((Guid) o);

Granted, the OP isn't going to do that directly, but anything that
involves a cast to Guid will potentially make this a run-time error.

> The second thing is that there is actually a "null guid" which is a
guid
with all zeros for values.

I think it's clearer to call that the "empty" GUID because:
1) It's available using Guid.Empty
2) It allows you to talk about a null Guid? vs a Guid? with a value of
Guid.Empty

I agree, I'm thinking of the COM context of referring to a null Guid,
which is where it all originated, of course. Thankfully, they didn't name
the null guid property on Guid Null.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

>
Jon

[Jon Skeet [C# MVP]]

On Aug 8, 3:46 pm, "Nicholas Paldino [.NET/C# MVP]"

Now, at runtime, you are going to have a problem further up in the
call
stack if you try and pass null.

No, that error will occur at compile time instead.

If you pass null directly to the method, yes, it will occur at compile
time, but I was thinking of this case:

object o = null;

string s = GetData((Guid) o);

Ah, yes. That would go bang regardless of the body of GetData, of
course.

Granted, the OP isn't going to do that directly, but anything that
involves a cast to Guid will potentially make this a run-time error.

True.

The second thing is that there is actually a "null guid" which is a
guid
with all zeros for values.

I think it's clearer to call that the "empty" GUID because:
1) It's available using Guid.Empty
2) It allows you to talk about a null Guid? vs a Guid? with a value of
Guid.Empty

I agree, I'm thinking of the COM context of referring to a null Guid,
which is where it all originated, of course. Thankfully, they didn't name
the null guid property on Guid Null.

Indeed. It wouldn't have seemed *too* bad in .NET 1.1, but with
nullable types it would have been pretty awful.

Jon