Posted By: PhrostByte | Jul 31st, 2005 @ 6:55 PM
page 1 of 1
Comments: 8 | Views: 4319
One thing I really wished was in C# 2.0 way to specify a method argument as "non-nullable".  Not having to manually check arguments for null would be a big plus in reducing and simplifying code.
Minh
Minh
WOOH! WOOH!
Couldn't you check for non-null condition inside the method body itself?

ie

if (retObj == null)
   throw new Exception("Hey, it's null");
else
   return retObj;
his point would be to get away from having to do that.
if the CLR could enforce it at runtime without you having to type it that would be sweet.
If there was a code generator in vs 2005 to generate parameter checking code automatically that would help to.
littleguru
littleguru
<3 Seattle
The framework supports also the ArgumentNullException for the checks... It's not so much work and it allows to customize the check..

if (foo == null)
    throw new ArgumentNullException("foo", "Foo is null.");
Minh
Minh
WOOH! WOOH!
PhrostByte wrote:
The point was to *not* do these checks, but have .NET check and throw the exception for you.  C# and .NET are geared toward quickly producing quality code and this could only help that - while I (grudgingly) check all my public methods I'm sure there are a lot of coders out there who just assume things will never be null.

Chances are you don't need a custom message, and if you do, don't mark it non-nullable and do the checks yourself.  It's a win-win idea.
But it's just so trivial. Programmers who forget to check for null values will just forget to mark their functions as non-nullable anyway.
So explain this to me.  What is the difference if you check for a null argument and throw a NullArgumentException - or if you reference a null object and get a NullReferenceException??

Either way you get an exception you have to handle.

nightski wrote:
So explain this to me.  What is the difference if you check for a null argument and throw a NullArgumentException - or if you reference a null object and get a NullReferenceException??

Either way you get an exception you have to handle.

You only get the NullReferenceException if you try to call a method or access a property.  Your method may not do either of them, it may only assign the argument to another variable.

 

But eventually you would get a NullReferenceException, correct?  I mean, if you never access a method or property what is the point of having the reference in the first place.

I am not arguing that checking for nulls is bad - but maybe throwing an exception is a little extreme?

I guess I wouldn't classify a developer as good or bad based on whether they check for nulls Smiley  It is all application specific anyways.


BTW - I think the original poster's idea is awesome.  A nice clean syntax for enforcing no nulls would be great.

I mean, do you guys complain about using(){} too?  I think anything that makes it easier for us developers is awesome.
page 1 of 1
Comments: 8 | Views: 4319
Microsoft Communities