String.Is​NullOrEmpty

This gem in C# throws an exception if the string is null.
Does this seem a bit silly to anyone else?

Echostorm wrote:

This gem in C# throws an exception if the string is null.
Does this seem a bit silly to anyone else?

How about

String myString = (String)(SomeObject.Results ?? String.Empty);

Echostorm wrote:

This gem in C# throws an exception if the string is null.

No it doesn't.

Are you calling String.IsNullOrEmpty(s); ?

It'll give you an exception if you call it like this:

String s;
s.IsNullOrEmpty(s);

but it's impossible for it not to do so in that case, because s is null.

littleguru wrote:



CannotResolveSymbol wrote: It'll give you an exception if you call it like this: String s; s.IsNullOrEmpty(s);

That's a compiler error. Calling a static method on an instance results in a compiler error.

I thought you could...  I guess I'm probably mixing up C# and Java (I'm 95% sure you can do that in Java).  Or maybe I'm just going crazy.

Maybe the next step would be to request the code snippet that is broken so we can see

littleguru wrote:



CannotResolveSymbol wrote: I thought you could...  I guess I'm probably mixing up C# and Java (I'm 95% sure you can do that in Java).  Or maybe I'm just going crazy.

No. Not possible in JAVA.

In C# it gets me a CS0176 error.

In Java, you can do it, but you can tell the compiler (e.g. in Eclipse) to mark it as a warning or even as an error.

Besides that, Java won't compile it as the variable might not have been initialized.

I'm pretty sure the vb.net compiler will allow access to shared members via a reference. It will warn though, I guess the compiler just evaluates the call to the type instead.

littleguru wrote:



stevo_ wrote: I'm pretty sure the vb.net compiler will allow access to shared members via a reference. It will warn though, I guess the compiler just evaluates the call to the type instead.

Yah. Might be that the VB.NET compiler is "intelligent" enough to translate it to a type call instead to an instance call.

There is no intelligence needed. You can't call a static method through an instance because it doesn't accept the this pointer in its parameter list. So even if the compiler lets you call it using the syntax of an instance method call, it still wouldn't throw an NRE because the this pointer isn't used.

In fact, in C++ this even goes for instance methods. E.g.:
class Foo
{
public:
   int Bar() { return 42; }
};

int main()
{
   Foo *f = NULL;
   cout << f->Bar();
   return 0;
}

This will print 42, and not cause an access violation. Because even though Bar is an instance method, it doesn't use the this pointer so it doesn't care whether the this pointer is NULL or not. Iirc this only works for non-virtual methods (which makes sense since it needs a vtable to call a virtual method).

Sven Groot wrote:



littleguru wrote:  stevo_ wrote: I'm pretty sure the vb.net compiler will allow access to shared members via a reference. It will warn though, I guess the compiler just evaluates the call to the type instead. Yah. Might be that the VB.NET compiler is "intelligent" enough to translate it to a type call instead to an instance call.

There is no intelligence needed. You can't call a static method through an instance because it doesn't accept the this pointer in its parameter list. So even if the compiler lets you call it using the syntax of an instance method call, it still wouldn't throw an NRE because the this pointer isn't used.

In fact, in C++ this even goes for instance methods. E.g.:
class Foo
{
public:
   int Bar() { return 42; }
};

int main()
{
   Foo *f = NULL;
   cout << f->Bar();
   return 0;
}

This will print 42, and not cause an access violation. Because even though Bar is an instance method, it doesn't use the this pointer so it doesn't care whether the this pointer is NULL or not. Iirc this only works for non-virtual methods (which makes sense since it needs a vtable to call a virtual method).

WRONG!!!!  I *HATE* seeing people give out misinformation of this calibre.  Your code above invokes undefined behavior, so the results you got are meaningless.  Not all compilers will behave this way.  Possibly not even the same compiler on different platforms and or of different versions.

It will throw a compiler error if you dont give the variable a value during declaration.  But the compiler may miss this depending on how you pass it into the method.

In any case you should always declare your variables as null when using them, why wouldnt you?

string s = null;
if (String.IsNullOrEmpty(s))
   Console.WriteLine("String is null or empty.");

Console.ReadLine();

ElucidWeb wrote:



It will throw a compiler error if you dont give the variable a value during declaration.  But the compiler may miss this depending on how you pass it into the method.

In any case you should always declare your variables as null when using them, why wouldnt you?

string s = null;
if (String.IsNullOrEmpty(s))
   Console.WriteLine("String is null or empty.");

Console.ReadLine();

How do you "throw a compiler error"?

And AFAIK, there's no way the compiler can miss an error here, at least in C#.  Pass it normally, or as a ref, and it will result in a compilation error.  Pass it as an out, and it will result in a compiler error if the called function references the variable prior to assigning to it.  There are no scenarios where you can reference an undefined variable in C#.

And I'm not certain how any of this is relevant to the original post mistakenly thinking IsNullOrEmpty() would throw an exception?