www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - [Suggestion] Classes and nulls.

reply AJG <AJG_member pathlink.com> writes:
Hi Walter,

I would like to know if it's possible for D to throw an exception when:

[a] You use the wrong operator to check for nullness (someNullClass == null).
[b] You try to access a class member thru a reference that is null
(someNullClass.method(), someNullClass.var, etc.).
[c] Any other similar situation dealing with null references and classes.

Currently, I'm getting segfaults for [a] and [b], and I have a try-catch wrapped
around it. I'm on Linux w/ 0.126.

Thanks,
--AJG.

PS: For the naysayers: yet another use for exceptions.

=======================
I sync, therefore I am.
Jun 29 2005
next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Thu, 30 Jun 2005 01:03:00 +0000 (UTC), AJG <AJG_member pathlink.com>  
wrote:

 Hi Walter,

 I would like to know if it's possible for D to throw an exception when:

 [a] You use the wrong operator to check for nullness (someNullClass ==  
 null).
 [b] You try to access a class member thru a reference that is null
 (someNullClass.method(), someNullClass.var, etc.).
 [c] Any other similar situation dealing with null references and classes.

 Currently, I'm getting segfaults for [a] and [b], and I have a try-catch  
 wrapped
 around it. I'm on Linux w/ 0.126.


Ahh.. on windows you can catch these. IIRC it's simply not implemented on  
*nix yet.
What are you catching? Once implemented you should be able to catch  
"Object". eg.

import std.stdio;

void main()
{
	char* p = null;
	
	try {
		*p = 0;
	}
	catch(Object o) {
		writefln("seg fault caught");
	}
}

Prints "seg fault caught" on windows.

Regan
Jun 29 2005
parent reply AJG <AJG_member pathlink.com> writes:
Ahh.. on windows you can catch these. IIRC it's simply not implemented on  
*nix yet.


Oh... well, if it's like that, I see then; I understand. *cough*second-class
citizens*cough*. ;)


What are you catching? Once implemented you should be able to catch  
"Object". eg.


Tried catch Exception and Object, same result.


import std.stdio;

void main() {
	char* p = null;
	
	try { *p = 0; }
	catch(Object o) { writefln("caught"); }
}
Prints "caught" on windows.


This example segfaults hard on Linux. Would be great if I could catch it...

Cheers,
--AJG.

=======================
I sync, therefore I am.
Jun 29 2005
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
AJG wrote:


Ahh.. on windows you can catch these. IIRC it's simply not implemented on  
*nix yet.


 
 Oh... well, if it's like that, I see then; I understand. *cough*second-class
 citizens*cough*. ;)


Well, I'm on GDC so... *cough* third-class cattle *cough* ;-)


import std.stdio;

void main() {
	char* p = null;
	
	try { *p = 0; }
	catch(Object o) { writefln("caught"); }
}
Prints "caught" on windows.


 
 
 This example segfaults hard on Linux. Would be great if I could catch it...


As a workaround you need to run it through the debugger,
or write your own signal handler to trap the segfault...
(I don't think Walter is ever going to make it Exceptions,
like having it throw stuff in non-release mode as suggested)

Here's what the "gdmd -g" and "gdb" dynamic duo outputs:
Program received signal EXC_BAD_ACCESS, Could not access memory.
0x00001f5c in _Dmain () at crash.d:6
6               try { *p = 0; }
(gdb)

That's on Mac OS X, by the way. Not really the same signals, but ?

--anders
Jun 30 2005
prev sibling next sibling parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
IMHO, when compiling with asserts, dbc, and etc. on... these would be 
useful.  After all, this code:

x = arr[5];

Has an implicit:

assert(arr.length >= 5 + 1);

Before it.  This is, yes, slower... but helps catch bugs, and their line 
numbers, etc.  So why not make this:

x = instance.x;

Have an implicit:

assert(instance !is null);

Which turns off similarly?  This could be, theoretically, even caught - 
I guess.  But the check would be gone in release, yes?

-[Unknown]



 Hi Walter,
 
 I would like to know if it's possible for D to throw an exception when:
 
 [a] You use the wrong operator to check for nullness (someNullClass == null).
 [b] You try to access a class member thru a reference that is null
 (someNullClass.method(), someNullClass.var, etc.).
 [c] Any other similar situation dealing with null references and classes.
 
 Currently, I'm getting segfaults for [a] and [b], and I have a try-catch
wrapped
 around it. I'm on Linux w/ 0.126.
 
 Thanks,
 --AJG.
 
 PS: For the naysayers: yet another use for exceptions.
 
 =======================
 I sync, therefore I am.
Jun 29 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
I believe the rationale against this is that the assert occurs in hardware  
(or something) already (by seg faulting) so why bother adding another  
check in ourselves. That said *nix needs to be able to catch it like can  
be done on windows.

Regan

On Wed, 29 Jun 2005 20:44:34 -0700, Unknown W. Brackets  
<unknown simplemachines.org> wrote:

 IMHO, when compiling with asserts, dbc, and etc. on... these would be  
 useful.  After all, this code:

 x = arr[5];

 Has an implicit:

 assert(arr.length >= 5 + 1);

 Before it.  This is, yes, slower... but helps catch bugs, and their line  
 numbers, etc.  So why not make this:

 x = instance.x;

 Have an implicit:

 assert(instance !is null);

 Which turns off similarly?  This could be, theoretically, even caught -  
 I guess.  But the check would be gone in release, yes?

 -[Unknown]



 Hi Walter,
  I would like to know if it's possible for D to throw an exception when:
  [a] You use the wrong operator to check for nullness (someNullClass ==  
 null).
 [b] You try to access a class member thru a reference that is null
 (someNullClass.method(), someNullClass.var, etc.).
 [c] Any other similar situation dealing with null references and  
 classes.
  Currently, I'm getting segfaults for [a] and [b], and I have a  
 try-catch wrapped
 around it. I'm on Linux w/ 0.126.
  Thanks,
 --AJG.
  PS: For the naysayers: yet another use for exceptions.
  =======================
 I sync, therefore I am.
Jun 29 2005
parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
Well, not hardware, but I get your point.  Still, it seems like line 
number and file name information would be nice - unless there's an easy 
and simple way to get that?

I haven't dealt that much with tracking down nulls except with a 
debugger.  I'm going to sound crazy here, but I hate debuggers. 
Annoying lot all of them.

-[Unknown]



 I believe the rationale against this is that the assert occurs in 
 hardware  (or something) already (by seg faulting) so why bother adding 
 another  check in ourselves. That said *nix needs to be able to catch it 
 like can  be done on windows.
 
 Regan
 
 On Wed, 29 Jun 2005 20:44:34 -0700, Unknown W. Brackets  
 <unknown simplemachines.org> wrote:
 

 IMHO, when compiling with asserts, dbc, and etc. on... these would be  
 useful.  After all, this code:

 x = arr[5];

 Has an implicit:

 assert(arr.length >= 5 + 1);

 Before it.  This is, yes, slower... but helps catch bugs, and their 
 line  numbers, etc.  So why not make this:

 x = instance.x;

 Have an implicit:

 assert(instance !is null);

 Which turns off similarly?  This could be, theoretically, even caught 
 -  I guess.  But the check would be gone in release, yes?

 -[Unknown]
Jun 29 2005
next sibling parent "Regan Heath" <regan netwin.co.nz> writes:
On Wed, 29 Jun 2005 23:41:37 -0700, Unknown W. Brackets  
<unknown simplemachines.org> wrote:

 Well, not hardware, but I get your point.


Yeah, I was waving my hands and hoping you would (I didn't really recall,  
and I don't really know how that all works).


 Still, it seems like line number and file name information would be nice  
 - unless there's an easy and simple way to get that?


I agree, it'd be nice. I know of no easy way.


 I haven't dealt that much with tracking down nulls except with a  
 debugger.  I'm going to sound crazy here, but I hate debuggers. Annoying  
 lot all of them.


I love the debugger (MSVC in my case). It allows me to 'know' what's  
happening and not rely on logging and guesswork. That said you can't  
always debug the situation because it's unique to a system or situation.  
In my ideal world a complete stack trace would be easily available in the  
event of a "crash".

Regan


 -[Unknown]



 I believe the rationale against this is that the assert occurs in  
 hardware  (or something) already (by seg faulting) so why bother adding  
 another  check in ourselves. That said *nix needs to be able to catch  
 it like can  be done on windows.
  Regan
  On Wed, 29 Jun 2005 20:44:34 -0700, Unknown W. Brackets   
 <unknown simplemachines.org> wrote:


 IMHO, when compiling with asserts, dbc, and etc. on... these would be   
 useful.  After all, this code:

 x = arr[5];

 Has an implicit:

 assert(arr.length >= 5 + 1);

 Before it.  This is, yes, slower... but helps catch bugs, and their  
 line  numbers, etc.  So why not make this:

 x = instance.x;

 Have an implicit:

 assert(instance !is null);

 Which turns off similarly?  This could be, theoretically, even caught  
 -  I guess.  But the check would be gone in release, yes?

 -[Unknown]
Jun 30 2005
prev sibling parent "Walter" <newshound digitalmars.com> writes:
"Unknown W. Brackets" <unknown simplemachines.org> wrote in message
news:da0470$7j5$1 digitaldaemon.com...

 Well, not hardware, but I get your point.  Still, it seems like line
 number and file name information would be nice - unless there's an easy
 and simple way to get that?


The debugger should put you on the source line that failed.
Jul 05 2005
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
AJG wrote:

 Hi Walter,
 
 I would like to know if it's possible for D to throw an exception when:
 
 [a] You use the wrong operator to check for nullness (someNullClass == null).


<snip>

The compiler would need to go out of its way to generate code to throw 
the exception for this special case.  So what would be the point of the 
compiler not reporting an error there and then?

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Jun 30 2005
parent AJG <AJG_member pathlink.com> writes:
Hi,

In article <da0hju$nof$2 digitaldaemon.com>, Stewart Gordon says...

 I would like to know if it's possible for D to throw an exception when:
 
 [a] You use the wrong operator to check for nullness (someNullClass == null).


<snip>

The compiler would need to go out of its way to generate code to throw 
the exception for this special case.  So what would be the point of the 
compiler not reporting an error there and then?


Oh, I agree completely. A compile-time error would be even better. But right now
I'm getting nothing but the segfault. So, in order of preference:
[1] Compile-time error ("Wrong operator used" or whatever).
[2] Exception thrown at run-time.
[3] Hard segfault (what happens now).

Cheers,
--AJG.

=======================
I sync, therefore I am.
Jun 30 2005