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: 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: 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: digitalmars.D/14342 Walter: 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: digitalmars.D/14342 Walter: 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.

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: digitalmars.D/14342 Walter: 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: 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: # cat null.d void main() { int* p = null; *p = 0; // oops } # gdc -o null null.d # gdc --version gdc (GCC) 3.3.5 (Apple patches from build 1495) [...] # ./null Bus error # gdc -o null -g null.d # gdb ./null 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 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: 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:

 # cat null.d
 void main()
 {
    int* p = null;
    *p = 0; // oops
 }

 # gdc -o null null.d
 # gdc --version                                gdc (GCC) 3.3.5 (Apple  
 patches from build 1495)
 [...]
 # ./null Bus error

 # gdc -o null -g null.d
 # gdb ./null
 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