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.

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

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.

>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.

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.

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]

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

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.

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]

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.