www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Redefining '==' with null

reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Q: Would there be much breakage, if '==' with
reference types was redefined from the current:

http://www.digitalmars.com/d/expression.html#EqualExpression

" For class objects, equality is defined as the result of calling
   Object.opEquals(). If one or the other or both objects are null,
   an exception is raised."

   (where "an exception is raised" means: it will dereference null)

into:

" For class objects, the result is true if both references are null.
   and false if one and only one of the object references is null.
   Otherwise, it returns the result of calling Object.opEquals()."

   (where opEquals returns an int, not bool, for "efficiency reasons")


It's OK if null and calling Object.opCmp still throws...
(as in "it's an error to compare objects if one is null")

Equality and sortability are somewhat different concepts.
(Just as equality and identity, but that's another thread)


But it would be nice if at least "== null" did not throw ?

--anders
Apr 12 2005
next sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Anders F Björklund" <afb algonet.se> wrote in message
news:d3g56v$26ov$1 digitaldaemon.com...

 Q: Would there be much breakage, if '==' with
 reference types was redefined from the current:

 http://www.digitalmars.com/d/expression.html#EqualExpression

 " For class objects, equality is defined as the result of calling
   Object.opEquals(). If one or the other or both objects are null,
   an exception is raised."

   (where "an exception is raised" means: it will dereference null)

 into:

 " For class objects, the result is true if both references are
 null.
   and false if one and only one of the object references is null.
   Otherwise, it returns the result of calling Object.opEquals()."

   (where opEquals returns an int, not bool, for "efficiency
 reasons")


Well, you only have to stay alive long enough to see everything come
back around.

FYI I led a long and erudite but thoroughly ineffective campaign on
this issue a couple of years ago.

Walter don't like it, and it ain't gonna happen.

:-(
Apr 12 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Matthew wrote:


 Well, you only have to stay alive long enough to see everything come
 back around.


Yes, it's somewhat harder to search the D newsgroups
for rejected suggestions than what it is with Bugzilla...

Must confess I failed to check the *old* newsgroup. :-P


 FYI I led a long and erudite but thoroughly ineffective campaign on
 this issue a couple of years ago.


OK, that smells like the Boolean Wars all over again.

Found some references;
Thread: http://www.digitalmars.com/d/archives/12144.html
Walter: http://www.digitalmars.com/drn-bin/wwwnews?D/13854


 Walter don't like it, and it ain't gonna happen.


Good to know. That puts D one step below Java, even...

(In Java, this.equals(null) returns false always -
while null.equals(this) throws NullPointerException)

In D, this still needs to be implemented on the Unix
side, as the "Error" is only thrown on Windows DMD ?)

--anders


D - "Can you still love me, with these ugly warts ?"
I - "Why don't you just have them removed instead ?"
Apr 12 2005
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
 Well, you only have to stay alive long enough to see everything 
 come
 back around.


 Yes, it's somewhat harder to search the D newsgroups
 for rejected suggestions than what it is with Bugzilla...

 Must confess I failed to check the *old* newsgroup. :-P


Don't worry about it. I never search. Who's got the bloody time?!


 FYI I led a long and erudite but thoroughly ineffective campaign 
 on
 this issue a couple of years ago.


 OK, that smells like the Boolean Wars all over again.

 Found some references;
 Thread: http://www.digitalmars.com/d/archives/12144.html
 Walter: http://www.digitalmars.com/drn-bin/wwwnews?D/13854


Yes, IIRC, it got the usual treatment: broad agreement by a 
majority, overruled by the minority.


 Walter don't like it, and it ain't gonna happen.


 Good to know. That puts D one step below Java, even...


No argument from me there. (I can't say this out loud, since I'm now 
the class flamer, but it seems to me D's dying by a million cuts. 
Each one's pretty low on the grand scale, but they combine to give a 
poor impression. But, I can't say that, so don't worry about it.)


 (In Java, this.equals(null) returns false always -
 while null.equals(this) throws NullPointerException)

 In D, this still needs to be implemented on the Unix
 side, as the "Error" is only thrown on Windows DMD ?)


That's a big problem, but as with many other issues, consistency 
across platforms is less important than what's simple or easy to do.


 --anders


 D - "Can you still love me, with these ugly warts ?"
 I - "Why don't you just have them removed instead ?"


Careful. You'll get a rep.
Apr 12 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Matthew wrote:


In D, this still needs to be implemented on the Unix
side, as the "Error" is only thrown on Windows DMD ?)


 
 That's a big problem, but as with many other issues, consistency 
 across platforms is less important than what's simple or easy to do.


I remember being somewhat surprised when it did not throw
an exception but segfaulted instead, but with the string
literals and the real type and the other platform-dependant
things I've stopped being too surprised about those things.

Fortunately, it's not much worse than what writing C/C++ is
when it comes to portability. Naturally, it's worse than Java.
(which amazingly enough is portable within their own platform,
you just have to watch out for bugs and for the major versions)


D - "Can you still love me, with these ugly warts ?"
I - "Why don't you just have them removed instead ?"


 
 Careful. You'll get a rep.


I wouldn't be here if I didn't find D attractive anyways :-)
And I find it better to know it's dead, that to keep hoping.

That a feature is dead, that was. Not the language itself. Yet.

--anders
Apr 12 2005
next sibling parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
You might be amused by this quote from 
http://www.digitalmars.com/d/errors.html:

"
No errors get inadvertently ignored.
Error exceptions get handled one way or another. There is nothing 
like a NULL pointer return indicating an error, followed by trying 
to use that NULL pointer.
"

:-)


"Anders F Björklund" <afb algonet.se> wrote in message 
news:d3g9j9$2apd$2 digitaldaemon.com...

 Matthew wrote:


In D, this still needs to be implemented on the Unix
side, as the "Error" is only thrown on Windows DMD ?)


 That's a big problem, but as with many other issues, consistency 
 across platforms is less important than what's simple or easy to 
 do.


 I remember being somewhat surprised when it did not throw
 an exception but segfaulted instead, but with the string
 literals and the real type and the other platform-dependant
 things I've stopped being too surprised about those things.

 Fortunately, it's not much worse than what writing C/C++ is
 when it comes to portability. Naturally, it's worse than Java.
 (which amazingly enough is portable within their own platform,
 you just have to watch out for bugs and for the major versions)


D - "Can you still love me, with these ugly warts ?"
I - "Why don't you just have them removed instead ?"


 Careful. You'll get a rep.


 I wouldn't be here if I didn't find D attractive anyways :-)
 And I find it better to know it's dead, that to keep hoping.

 That a feature is dead, that was. Not the language itself. Yet.

 --anders
Apr 12 2005
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Anders F Björklund" <afb algonet.se> wrote in message
news:d3g9j9$2apd$2 digitaldaemon.com...

 I remember being somewhat surprised when it did not throw
 an exception but segfaulted instead,


Seg faulting is throwing an exception - it's just done by the hardware. You
can even catch them:


int main()
{
    int* p;

    try
    {
       *p = 3;
    }
    catch (Object o)
    {
         printf("caught the exception: %.*s\n", o.toString());
    }
    return 0;
}

Running it gives:

    C:>test
    caught the exception: Access Violation
Apr 18 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Walter wrote:


I remember being somewhat surprised when it did not throw
an exception but segfaulted instead,


 
 Seg faulting is throwing an exception - it's just done by
 the hardware. You can even catch them:


It is, in the broad sense, I suppose... But I was more kinda
expecting a subclass of class Exception being thrown, rather
than a signal handler being invoked by the operating system.

Anyway, I thought we cleared all that up - way back then ?
(the solution being to add such handlers for other OS too)


 Running it gives:
 
     C:>test
     caught the exception: Access Violation


Yeah, or:

$ ./test
Bus error

It depends a little on the platform... ;-)

But it seems like having "null == this" return false is out
of the question, so I will just leave this thread at that.

--anders
Apr 18 2005
parent reply Daniel Horn <hellcatv hotmail.com> writes:
Anders F Björklund wrote:

 
 But it seems like having "null == this" return false is out
 of the question, so I will just leave this thread at that.
 
 --anders


Absolutely not out of the question:

I don't understand the difficulty here--this is the major obstacle in 
porting java code

I suggest walter does some syntactic sugar transformations here:
change
A==B
to
(A===null?(B===null):(B===null?false:A.opEqual(B)))

then if people don't want that overhead they can explicitly call 
A.opEqual(B);

and the beauty of this solution is that it keeps *all* working code in 
tact, yet it improves robustness of Java portation. And in addition 
there are NO performance implications (if you are in the know and this 
is the inner loop (why oh why are you using virtual functions then), use 
.opEqual

(unless it relies on that caught access violation garbage--in which case 
it wasn't working in the first place)
Apr 19 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Daniel Horn wrote:


 But it seems like having "null == this" return false is out
 of the question, so I will just leave this thread at that.





 Absolutely not out of the question:


I just meant that just like a boolean type this has been suggested,
and rejected, for addition in the D language multiple times already ?

Arguing about the decision here, doesn't seem to make it more likely...
I guess someone just gets to write a book about it. "Imperfect D" ? ;-)


 I don't understand the difficulty here--this is the major obstacle in 
 porting java code
 
 I suggest walter does some syntactic sugar transformations here:
 change
 A==B
 to
 (A===null?(B===null):(B===null?false:A.opEqual(B)))
 
 then if people don't want that overhead they can explicitly call 
 A.opEqual(B);
 
 and the beauty of this solution is that it keeps *all* working code in 
 tact, yet it improves robustness of Java portation. And in addition 
 there are NO performance implications (if you are in the know and this 
 is the inner loop (why oh why are you using virtual functions then), use 
 .opEqual


No argument there, and this was exactly my (rejected) suggestion too...
(usually, there is also a short path for "this is object" in opEquals)

But Walter thinks that comparing something (Object) with null is outside
the contract of '==', and thus should trigger an Exception to be thrown.

That it is a hardware signal trap that is throwing the Exception in
question, that is just an optimization - as far as I've understood it ?


For the time being, unless there is *major* shift in how things work
around here - this is just yet another big thing to be aware of in D. :(

See http://www.prowiki.org/wiki4d/wiki.cgi?ShortFrequentAnswers:

- Comparing an object reference like: "if (object == null)" will crash.
   You must use "if (object is null)"

- Checking for a key in an AA like: "if(array[key])" will create it if
   it's missing. You must use "if(key in array)"

The second being totally unrelated, except that it also traps up people
from outside regularly and is another frequent suggestion for change....

--anders


PS. I thought it could working something similar to this old suggestion:
http://cdsmith.twu.net/professional/java/pontifications/comparison.html
(it also suggests "inlining" '==' as '===', if both are of type Object?)
Apr 19 2005
parent reply Georg Wrede <georg.wrede nospam.org> writes:
Anders F Björklund wrote:

 Daniel Horn wrote:
 

 But it seems like having "null == this" return false is out
 of the question, so I will just leave this thread at that.




 
 

 Absolutely not out of the question:


 
 
 I just meant that just like a boolean type this has been suggested,
 and rejected, for addition in the D language multiple times already ?
 
 Arguing about the decision here, doesn't seem to make it more likely...
 I guess someone just gets to write a book about it. "Imperfect D" ? ;-)
 

 I don't understand the difficulty here--this is the major obstacle in 
 porting java code

 I suggest walter does some syntactic sugar transformations here:
 change
 A==B
 to
 (A===null?(B===null):(B===null?false:A.opEqual(B)))

 then if people don't want that overhead they can explicitly call 
 A.opEqual(B);

 and the beauty of this solution is that it keeps *all* working code in 
 tact, yet it improves robustness of Java portation. And in addition 
 there are NO performance implications (if you are in the know and this 
 is the inner loop (why oh why are you using virtual functions then), 
 use .opEqual


 
 
 No argument there, and this was exactly my (rejected) suggestion too...
 (usually, there is also a short path for "this is object" in opEquals)
 
 But Walter thinks that comparing something (Object) with null is outside
 the contract of '==', and thus should trigger an Exception to be thrown.
 
 That it is a hardware signal trap that is throwing the Exception in
 question, that is just an optimization - as far as I've understood it ?
 
 
 For the time being, unless there is *major* shift in how things work
 around here - this is just yet another big thing to be aware of in D. :(
 
 See http://www.prowiki.org/wiki4d/wiki.cgi?ShortFrequentAnswers:
 
 - Comparing an object reference like: "if (object == null)" will crash.
   You must use "if (object is null)"


This is unfortunate, indeed.

One might say that creating gratuituous (and unobvious) traps for 
newcomers to a new language is not good for the language.

The only excuse for still having this would be some important 
consistency issue. Something akin to the many things where early C made 
some "conveniences" in syntax, resulting in 30 years of grief for mankind.

For the moment, though, I cannot see such a major excuse. (There might 
be one, but it would behoove Walter to explain it carefully.)


 - Checking for a key in an AA like: "if(array[key])" will create it if
   it's missing. You must use "if(key in array)"


Same thing here.

If there is a good motivation for if(array[key]) silently inserting the 
key, then so be it. BUT THEN this should be VERY prominently in the 
documentation. AND with a proper explanation of the reason this is so.

      People can accept pretty much anything
        -- as long as they clearly see why.



 The second being totally unrelated, except that it also traps up people
 from outside regularly and is another frequent suggestion for change....
 
 --anders
 
 
 PS. I thought it could working something similar to this old suggestion:
 http://cdsmith.twu.net/professional/java/pontifications/comparison.html
 (it also suggests "inlining" '==' as '===', if both are of type Object?)
Apr 19 2005
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Georg Wrede wrote:


 If there is a good motivation for if(array[key]) silently inserting the 
 key, then so be it. BUT THEN this should be VERY prominently in the 
 documentation. AND with a proper explanation of the reason this is so.


I think the insertion of missing keys is so it can double as a lvalue:

int[ char[] ] dictionary;

char[] word;

     dictionary[word]++;


Someone mentioned on the thread that talked about the AAs, that it would
be possible to have it insert when used as a lvalue, and not insert when
used as a rvalue. If this could be done, it would clear it up a little ?

Another possibility discussed earlier was throwing an Exception, akin
to comparing something with null. (I thought it should return key.init,
at least when being used as an rvalue - instead of throwing up anything)


I think the "if(array[key])" is just an innocent bystander to all this,
caught in the crossfire. Can't think of any reason to make it insert ?
("array[key];" also inserts, by the way. And still fails to .init, too)

There seems to be at least three different ideas on how it should work:

1)
Have comparisons with null just dereference null (A.V./SEGV/B.E.)
Have retrievals of non-existing keys create and insert them in AA

2)
Have comparisons with null throw Exceptions (call a _d_XXX handler)
Have any non-existing keys throw Exceptions (call a _d_XXX handler)

3)
Define all comparisons with null, as fixed values (true/false)
Return default values (.init) for non-existing keys, no insert

It's a matter of how the operations are defined, in the specification ?
(and I agree that it could use some more explanation and details there)


Note that this is talking about "null == this" and "hash[key]" *only*.

You can still rewrite both of them, as "null is this" or "key in hash".
Neither alternate expression will throw exceptions or create new keys.

Of course, that requires rewriting... (which makes it a porting trap)

--anders


PS.
I'm writing "null == this" here instead of "this == null", since the
latter doesn't always cause such failures in D, just occasionally ?
(and using a form that always does, makes it more clear in the above)

In some languages, they are even defined differently... (e.g. in
Java: "null.equals(this)" throws, but "this.equals(null)" is false)
A main example of a language using the third form 3) would be Perl.
Apr 19 2005
prev sibling parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
"Anders F Björklund" <afb algonet.se> wrote in message
news:d3g56v$26ov$1 digitaldaemon.com...

 Q: Would there be much breakage, if '==' with
 reference types was redefined from the current:

 http://www.digitalmars.com/d/expression.html#EqualExpression

 " For class objects, equality is defined as the result of calling
   Object.opEquals(). If one or the other or both objects are null,
   an exception is raised."

   (where "an exception is raised" means: it will dereference null)


It's interesting the doc says "one or the other" since it only errors if the
left hand reference is null.


 into:

 " For class objects, the result is true if both references are null.
   and false if one and only one of the object references is null.
   Otherwise, it returns the result of calling Object.opEquals()."


The only downsides to this would be:
1) it would made opEquals different from opAdd and other overloadable
operators.
2) it decreases performance slightly since it has to do the null checks

I think the doc in that section needs to be replaced with the description in 
http://www.digitalmars.com/d/operatoroverloading.html
"The expression (a == b) is rewritten as a.opEquals(b), and (a != b) is 
rewritten as !a.opEquals(b). "


 It's OK if null and calling Object.opCmp still throws...
 (as in "it's an error to compare objects if one is null")

 Equality and sortability are somewhat different concepts.
 (Just as equality and identity, but that's another thread)


I think D approaches opEqual and opCmp as quite similar actually. More 
similar than equality and identity.


 But it would be nice if at least "== null" did not throw ?


yup - but I'm not holding my breath and with good tools the problem 
hopefully won't be too bad.
Apr 12 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Ben Hinkle wrote:


" For class objects, equality is defined as the result of calling
  Object.opEquals(). If one or the other or both objects are null,
  an exception is raised."

  (where "an exception is raised" means: it will dereference null)


 
 It's interesting the doc says "one or the other" since it only errors if the
 left hand reference is null.


Well, it can segv with the right hand side too - with overloads...
But it is more certain segv with the left hand side null, true.


 The only downsides to this would be:
 1) it would made opEquals different from opAdd and other overloadable
 operators.


This is a considerable downside, and thanks for bringing it up.


 2) it decreases performance slightly since it has to do the null checks


I'm somehow suspecting this the main reason it's the way it is.


 I think the doc in that section needs to be replaced with the description in 
 http://www.digitalmars.com/d/operatoroverloading.html
 "The expression (a == b) is rewritten as a.opEquals(b), and (a != b) is 
 rewritten as !a.opEquals(b). "


At least the page doesn't say "eq" anymore (the old opEquals name)

Fixing the crossreferences and providing more detail would be nice.


Equality and sortability are somewhat different concepts.
(Just as equality and identity, but that's another thread)


 
 I think D approaches opEqual and opCmp as quite similar actually. More 
 similar than equality and identity.


It does, in fact it does so even more than Java does.

In Java, thing.equals(null) just returns false - but
thing.compareTo(null) throws a NullPointerException...

http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Comparable.html

--anders
Apr 13 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Wed, 13 Apr 2005 09:13:38 +0200, Anders F Björklund <afb algonet.se>  
wrote:

 2) it decreases performance slightly since it has to do the null checks


 I'm somehow suspecting this the main reason it's the way it is.


So can't it be treated similarly to array bounds checks? only done if not  
-release mode.

Regan
Apr 14 2005
parent reply =?ISO-8859-15?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Regan Heath wrote:


 2) it decreases performance slightly since it has to do the null checks


 I'm somehow suspecting this the main reason it's the way it is.


 
 So can't it be treated similarly to array bounds checks? only done if 
 not  -release mode.


I think Walter said he preferred the hardware to do the null pointer 
checks, even in the -release builds... (i.e. trap the hardware signal)

Thread: http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/14342
Walter: http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/14440

And redefining == with objects seem to be totally out of the question.
(i.e. making equality comparisions with null a legal/defined operation)

--anders
Apr 14 2005
next sibling parent reply xs0 <xs0 xs0.com> writes:
Anders F Björklund wrote:

 Regan Heath wrote:
 

 2) it decreases performance slightly since it has to do the null checks



 I'm somehow suspecting this the main reason it's the way it is.



 So can't it be treated similarly to array bounds checks? only done if 
 not  -release mode.


 
 
 I think Walter said he preferred the hardware to do the null pointer 
 checks, even in the -release builds... (i.e. trap the hardware signal)
 
 Thread: http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/14342
 Walter: http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/14440
 
 And redefining == with objects seem to be totally out of the question.
 (i.e. making equality comparisions with null a legal/defined operation)
 
 --anders


Hmm, why not make ==null or null== totally illegal in the first place? I 
mean, "if (a=func())" is illegal, and it can actually be what the user 
wanted; opCmp(null) is practically never what is wanted, so a compiler 
error should be issued and solve this without any special handling of ==.

Just my thoughts..


xs0
Apr 14 2005
parent =?ISO-8859-15?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
xs0 wrote:


 Hmm, why not make ==null or null== totally illegal in the first place?


They are now. Just not flagged at compile-time, but at run-time instead:
"If one or the other or both objects are null, an exception is raised."

Allowing '== null' was mostly to make it simpler to convert from C/Java,
or from using a "struct*" and then changing to using an Object instead ?
(although '==' has a different meaning for pointers and for references,
which is discussed in great detail in the other thread about '=='/'===')


It's mostly likely possible to have the D compiler catch these two
common errors, or perhaps have a "dlint" tool as a secondary option.

And having the compiler catch it, would probably be better than now too.
I was just discussing the alternative; of making it a legal operation ?


Note that the compiler can probably not catch the "dynamic" alternative,
such as when you have: "Object x,y; if (x == y) { ... }", and so on...

--anders
Apr 14 2005
prev sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Thu, 14 Apr 2005 13:27:17 +0200, Anders F Björklund <afb algonet.se>  
wrote:

 Regan Heath wrote:


 2) it decreases performance slightly since it has to do the null  
 checks


 I'm somehow suspecting this the main reason it's the way it is.


  So can't it be treated similarly to array bounds checks? only done if  
 not  -release mode.


 I think Walter said he preferred the hardware to do the null pointer  
 checks, even in the -release builds... (i.e. trap the hardware signal)

 Thread: http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/14342
 Walter: http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/14440


So we already have a null pointer exception, sort of, called Exception.

Next question, is there any reason to create and throw a spcific exception  
for this i.e. NullPtrException? I'm thinking "no" because what possible  
reason would an application have for catching that specifically?

However.. the error message is simply "Access Violation" with no file/line  
information. So, my suggestion is that in non -release builds i.e. builds  
in which array bounds and other checks are performed, the error message  
should read something like "Accessed null reference at file:line".

Regan
Apr 15 2005
parent reply =?ISO-8859-15?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Regan Heath wrote:


 So we already have a null pointer exception, sort of, called Exception.


Yeah, "sort of", on Windows. The segfault catcher for Linux was:
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/20190


 Next question, is there any reason to create and throw a spcific 
 exception  for this i.e. NullPtrException? I'm thinking "no" because 
 what possible  reason would an application have for catching that 
 specifically?


Depends on if you want to separate exceptions on name, or on class ?
Also, "Access Violation" is a Windows term... It has other names too.


 However.. the error message is simply "Access Violation" with no 
 file/line  information. So, my suggestion is that in non -release builds 
 i.e. builds  in which array bounds and other checks are performed, the 
 error message  should read something like "Accessed null reference at 
 file:line".


Yeah, that was I thought too - in the original post / suggestion. But
Walter preferred the hardware solution. Besides, GDB shows the line:


void main()
{
   int* p = null;
   *p = 0; // oops
}



                               gdc (GCC) 3.3.5 (Apple patches from build 
1495)
[...]


Bus error



GNU gdb 5.3-20030128 (Apple version gdb-330.1)
[...]
Program received signal EXC_BAD_ACCESS, Could not access memory.
0x0000217c in _Dmain () at null.d:4
4         *p = 0; // oops
(gdb)

For debugging, I think I even *prefer* that over an anymous exception ?
(I'm not sure how you can get Windows debuggers to trap at the "*null")


But - the original question in this thread was whether "null == this"
should dereference null, or if it should simply be *defined* as false.

And it seems like the dereference/exception way is preferred by D :
Walter http://www.digitalmars.com/drn-bin/wwwnews?D/13854


So I consider this thread closed. AV/SEGV/BE is the designed behaviour.
Also, "this == null" doesn't do it *every* time. Just in some cases...

But it does make the pitfall for old java programmers all the greater.
(since "==" will not just be a little slower, but throw Exceptions...)

--anders
Apr 16 2005
parent "Regan Heath" <regan netwin.co.nz> writes:
On Sat, 16 Apr 2005 10:15:14 +0200, Anders F Björklund <afb algonet.se>  
wrote:

 Regan Heath wrote:


 So we already have a null pointer exception, sort of, called Exception.


 Yeah, "sort of", on Windows. The segfault catcher for Linux was:
 http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/20190


I believe Walter intends to make sure that all D's features operate on all  
platforms that can support them.


 Next question, is there any reason to create and throw a spcific  
 exception  for this i.e. NullPtrException? I'm thinking "no" because  
 what possible  reason would an application have for catching that  
 specifically?


 Depends on if you want to separate exceptions on name, or on class ?
 Also, "Access Violation" is a Windows term... It has other names too.


True. However I was thinking about it from the other direction, assuming  
we call it something would you ever want to catch it? What would you do  
with it once you caught? There seems little point to catching it to me.  
Thus, a better error string is all I'd like.


 However.. the error message is simply "Access Violation" with no  
 file/line  information. So, my suggestion is that in non -release  
 builds i.e. builds  in which array bounds and other checks are  
 performed, the error message  should read something like "Accessed null  
 reference at file:line".


 Yeah, that was I thought too - in the original post / suggestion. But
 Walter preferred the hardware solution.


As do I, for -release builds where performance is desire. However, while  
debugging I prefer a nice error message containing file and line number  
whenever possible.


 Besides, GDB shows the line:


 void main()
 {
    int* p = null;
    *p = 0; // oops
 }



 patches from build 1495)
 [...]




 GNU gdb 5.3-20030128 (Apple version gdb-330.1)
 [...]
 Program received signal EXC_BAD_ACCESS, Could not access memory.
 0x0000217c in _Dmain () at null.d:4
 4         *p = 0; // oops
 (gdb)

 For debugging, I think I even *prefer* that over an anymous exception ?
 (I'm not sure how you can get Windows debuggers to trap at the "*null")


An exception that prints file and line number is more useful. Beta testers  
are unlikely to be running the app in a debugger (in my experience).


 But - the original question in this thread was ..


I wasn't interested in the original question. Sorry for hijacking the  
thread.

Regan
Apr 16 2005