Hi All,
When i tried to execute my ASP.Net Application, I got the Runtime error in IE " 'null' is null or not an object ". Im using Visual Studio.Net 2005 and using some Ajax Controls in my application. If i click some Events, it shows the above message. Please help me to do .... Very thankful to you .....

Null means it is nothing. It has no value or state of any kind.

I asked if there is any Solution for that error.

There's probably a solution to the specific problem in your code that's causing the error message. But it's an oft-encountered message and doesn't indicate anything by itself; just that a dereferencing problem occured somewhere. Is it an error in clientside Javascript or server ASP code? Post code if you have some idea where the problem may be... but, please don't post masses of code. Does the error have a line number? if so, post that line, and the block that the line is in ( i.e. the function it's in )

Several thoughts:

- The word "null" is a JS keyword. You can't use it for a variable, object, function, or id name.

- You could be trying to use a variable initially set as a pointer after its value has been changed to a non-pointer. This is usually the result of a typogoofical error.

- Did you forget to make variables local to functions? If so, two different functions might be using the same global variable for different purposes.

- Is your ISP adding ads to your page? if so, their code might be interacting with your code.

remember one thing very clearly that null is nothing. even null is not equal to null. variable initializing may fix your problem.

<html>
	<head>
		<script language="javascript">
			function nullTest()
			{
				var test=null;
				
				if(document.getElementById('email').value===test)
				{
					alert("Yes null equal to null");
				}
				else
					alert("No null is not equal to null");
					
			}
		</script>
	</head>
	<body>
		<form onsubmit='nullTest();'>
			<p>Email	:
			<input  id="email" type="text" value=""/>
			<input  type="submit" value="Submit"/>
		</form>
	</body>
</html>

All that code proves is that null is not equal to the empty string. The value of the 'email' field will not be initialized to null, it'll be initialized to "".

However -- and it would be quite annoying otherwise -- null certainly compares to null.

Null also compares to undefined: ( undefined == null ) is always true.

This is a rather old thread aswel ( it's been 10 months ). I imagine that the original poster has fixed the problem, by now.

> Null also compares to undefined: ( undefined == null ) is always true.

...which is often misleading as they stand for two different things and have different types. A better way in almost all cases would be to use the strict comparison operator to get an accurate, type safe result.

Well, yeah. ( undefined == null ) only works via type coercion.
IMO, more useful ( and pleasant reading ) than either is to coerce straight to boolean;

if( x ) {
// where x may be null, undefined, or an object
}

But only because I'd rarely make a meaningful working distinction between ( or differently handle ) an object variable being null or being undefined.

> But only because I'd rarely make a meaningful working distinction between ( or differently
> handle ) an object variable being null or being undefined. null is a valid value, undefined is *nothing*. Undefined has a special significance in the sense that attempting to retrieve value for a non-existent key from a Javascript object returns undefined . Simply put, the distinction is important when:

if(x) {
  // do something
}

isn't acceptable. :-)

Of course, there are sometimes occasions where the distinction is meaningful, but === undefined or === null aren't always the most useful, consider:

if( x !== undefined ) {
  x.something( );
  //Possible error, if x happens to be null:
  //""null is null or not an object""
  //or something along those lines
}

Can, of course use if ( ( x !== undefined ) & ( x !== null ) ) , but it doesn't really gain very much over if( x ) .

Using a typeof test ( AND a non-null test ) is probably the most effective, in most places.

> Can, of course use if ( ( x !== undefined ) & ( x !== null ) ) , but it doesn't really gain
> very much over if( x ) .

Err..no, it very much does since blank strings, the boolean value false and the integer 0 all evaluate to false. Consider:

var person = {name: "sos", hostile: false, description: ''};

if(person["hostile"]) {
  // Even though a mapping exists for they key 'hostile', 
  // the program flow doesn't enter this block.
}

if(person["description"]) {
  // ditto here.
}

Also it is much better to base your test of undefined on typeof rather than comparison operator since comparison fails for non-existent variables. Consider the following two almost similar snippets. The first one doesn't work, the second one does:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
            "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
    <meta http-equiv="Script-Content-Type" content="text/javascript">
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    <title>Test</title>
</head>
<body>
  <script type="text/javascript">
  alert(a === undefined);  
  </script>  
</body>
</html>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
            "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
    <meta http-equiv="Script-Content-Type" content="text/javascript">
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    <title>Test</title>
</head>
<body>
  <script type="text/javascript">
  alert(typeof a === "undefined");
  </script>  
</body>
</html>

Ouch. I'd rather prefer to know if something is or isn't an object a string, a boolean, a null, etc. Hence typeof. Only testing ( x !== undefined ) and/or ( x !== null ) isn't atall helpful if I still have no idea what I can subsequently do with x.

The test I'd usually use is ( If I have absolutely no idea what x might be, and I'm hoping for an object for example ):

if( ( typeof x == "object " ) && x ) {
  //do whatever ( i.e. poke around in x .looking for the method/property I need ) [ the && x is needed because typeof null is "object" ]
}

But, more often than not, I'd have a good idea what x is going to be, and would normally only ever use null as placeholder for things that I'm sure are only going to otherwise be objects, so, any tests can be more simply put ( assuming of course, that I control ALL of the functions involved ):

var x = get_x_or_null( );
if( ! x ) {
  x = try_something_else_to_get_x_or_null( );
}
//etc, etc.

Otherwise, for the heterogenous collection.. I'd try and setup a convention for each value, or use a "real class" with a constructor/properties/etc.

If I'm expecting an object and I pull out a null ( or an undefined ) its probably, although not always, going to amount to the same recovery, e.g.:

//I'm gonna keep _only_ object pointers to Whatever objects in here.
var xx = Object( );
var a = xx[ "a" ];
if( ! a ) {
  //don't care if a is null or undefined, I need to do something with a Whatever.
  xx[ "a" ] = a = new Whatever( );
}
a.do_something( );

But yeh, that only works if you keep the collection homogenous..

> But, more often than not, I'd have a good idea what x is going to be, and would normally
> only ever use null as placeholder for things that I'm sure are only going to otherwise be
> objects

Again fails if you end up explicitly constructing Boolean, String and Number objects since they suffer with the same drawbacks as their primitive counterparts.

> But yeh, that only works if you keep the collection homogenous..

...which almost never is the case with real world Javascript object literals. :-)

Anyways, the intent of my posts was not to nitpick at the code snippets which almost always work in normal cases, but to make it clear to the OP that dark corners do exist in the happy go lucky world of Javascript.

Again fails if you end up explicitly constructing Boolean, String and Number objects since they suffer with the same drawbacks as their primitive counterparts.

That's something I never considered.

I don't consider coercion in and of itself a bad thing ( coercion between numeric types is a must ).. but.. implicitly having numbers converted to strings and back really is hellish, and conversion between objects and primitives in a language without pointers ( or some other equivelent layer of [de]referencing ) isn't nice either.

There's quite alot of dark corners, but most can be avoided, as long as you know what to expect.

This article has been dead for over six months. Start a new discussion instead.