I don't find anything in the documentation about that:
Should D make any run-time check whether a reference to an object is null
or not, before it calls a member function?

I wrote the attached program and it hangs up (CTRL-C can terminate :-)
if I left out the marked line.

Obviously there is a bug in my program in this case. The reference variable was created only and no physical object.

I think it is a typical problem for C++ programmers when starting to use D. First I tought the object instance will be created...

This bug can be caught only before the call is made to I_don't_know_where, the CPU does not call the member where the catch would also be possible.

A run-time check for null (with an exception thrown if needed) would be fine or is any other solution?

Thanks in advance,
Tamas

--------------------------
import c.stdio;

class xRecord{
int b;

this() {b=3;}
void set(int x)
{
if(this==null)
{
throw new Error("OOOooooppppsss !");
}
else
{
printf("The value of _this_: %p\n",this);
}
b=x;
}
}

void main(char[][] args)
{
xRecord xr2;
//    xr2=new xRecord();	//*********************************

printf("start\n");

if(xr2==null)
{
printf("xr2 is null\n");
}
else
{
printf("xr2 is: %p\n",xr2);
}

xr2.set(10); // hangs up if xr2 equals to null

printf("finish\n");
}
--------------------------------

Tamas Nagy
MicroWizard Ltd.
Hungary

microwizard@.ax.hu

Null pointer dereferences should GP fault, not hang. Since the hardware does the check for free, there's no profit to adding it into the language. Remember, you can write exception handlers to catch GP fault exceptions.

"MicroWizard" <MicroWizard_member@pathlink.com> wrote in message news:ab388k$2ao0$1@digitaldaemon.com...
> I don't find anything in the documentation about that:
> Should D make any run-time check whether a reference to an object is null
> or not, before it calls a member function?
>
> I wrote the attached program and it hangs up (CTRL-C can terminate :-)
> if I left out the marked line.
>
> Obviously there is a bug in my program in this case. The reference variable was created only and no physical object.
>
> I think it is a typical problem for C++ programmers when starting to use D. First I tought the object instance will be created...
>
> This bug can be caught only before the call is made to I_don't_know_where, the CPU does not call the member where the catch would also be possible.
>
> A run-time check for null (with an exception thrown if needed) would be fine or is any other solution?
>
> Thanks in advance,
> Tamas
>
> --------------------------
> import c.stdio;
>
> class xRecord{
> int b;
>
> this() {b=3;}
> void set(int x)
> {
> if(this==null)
> {
> throw new Error("OOOooooppppsss !");
> }
> else
> {
> printf("The value of _this_: %p\n",this);
> }
> b=x;
> }
> }
>
> void main(char[][] args)
> {
> xRecord xr2;
> //    xr2=new xRecord(); //*********************************
>
> printf("start\n");
>
> if(xr2==null)
> {
> printf("xr2 is null\n");
> }
> else
> {
> printf("xr2 is: %p\n",xr2);
> }
>
> xr2.set(10); // hangs up if xr2 equals to null
>
> printf("finish\n");
> }
> --------------------------------
>
> Tamas Nagy
> MicroWizard Ltd.
> Hungary
>
> microwizard@.ax.hu

"Walter" <walter@digitalmars.com> wrote in message news:ab426r$310j$3@digitaldaemon.com...

> Null pointer dereferences should GP fault, not hang. Since the hardware
does
> the check for free, there's no profit to adding it into the language. Remember, you can write exception handlers to catch GP fault exceptions.

But still... not every hardware does, and even then, I'd like to see
the message explaining what REALLY happened, and not just another cryptic
GP error "info".

"Pavel Minayev" <evilone@omen.ru> wrote in message news:ab45q3$39j$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:ab426r$310j$3@digitaldaemon.com...
>
> > Null pointer dereferences should GP fault, not hang. Since the hardware
> does
> > the check for free, there's no profit to adding it into the language. Remember, you can write exception handlers to catch GP fault exceptions.
>
> But still... not every hardware does, and even then, I'd like to see
> the message explaining what REALLY happened, and not just another cryptic
> GP error "info".
>


Yep. "Null pointer dereferenced at line #25: mynullpointer->DoSomething();" would be a thousand times more valuable than "MYDAPP.EXE caused a general protection fault at address 34EF:4FEC: read of address 0000:0000"...


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail

Pavel Minayev wrote:
> "Walter" <walter@digitalmars.com> wrote in message
> news:ab426r$310j$3@digitaldaemon.com...
> 
> 
>>Null pointer dereferences should GP fault, not hang. Since the hardware
> 
> does
> 
>>the check for free, there's no profit to adding it into the language.
>>Remember, you can write exception handlers to catch GP fault exceptions.
> 
> 
> But still... not every hardware does, and even then, I'd like to see
> the message explaining what REALLY happened, and not just another cryptic
> GP error "info".

Can we get Walter to standardize an exception object
to catch general protection faults? Then every developer
could display the GPF to the user in the way they found
most useful.

-R

In article <ab4729$4qa$1@digitaldaemon.com>,
 "OddesE" <OddesE_XYZ@hotmail.com> wrote:

> "Pavel Minayev" <evilone@omen.ru> wrote in message news:ab45q3$39j$1@digitaldaemon.com...
> > "Walter" <walter@digitalmars.com> wrote in message news:ab426r$310j$3@digitaldaemon.com...
> >
> > > Null pointer dereferences should GP fault, not hang. Since the hardware
> > does
> > > the check for free, there's no profit to adding it into the language. Remember, you can write exception handlers to catch GP fault exceptions.
> >
> > But still... not every hardware does, and even then, I'd like to see
> > the message explaining what REALLY happened, and not just another cryptic
> > GP error "info".
> >
> 
> 
> Yep. "Null pointer dereferenced at line #25: mynullpointer->DoSomething();" would be a thousand times more valuable than "MYDAPP.EXE caused a general protection fault at address 34EF:4FEC: read of address 0000:0000"...

Have you ever read the following... <http://www.smalltalkchronicles.net/edition2-1/null_object_pattern.htm>

snip:

   If you answer nil in Objective-C, the nil that is returned
   is, in some respects, a lot like Smalltalk¹s nil, except
   that instead of the nil generating exceptions when you
   message it, it just silently eats the messages. Thus,
   in Objective-C, nil acts more like a "black hole". It
   is emptiness. It is nothingness. If you send anything to
   nil, nil is all you get back. No exceptions. No
   return values. Nothing.

   Obviously, if we wanted this same behavior in Smalltalk,
   we would simply override the #doesNotUnderstand:
   instance message of the UndefinedObject class to
   just answer self.

The interesting thing is that Objective-C has had a silent 'nil' for over a decade, and it didn't prevent a bunch of good software from being written...
-- 
C. Keith Ray

<http://homepage.mac.com/keithray/xpminifaq.html>

OddesE wrote:

> "Pavel Minayev" <evilone@omen.ru> wrote in message
> news:ab45q3$39j$1@digitaldaemon.com...
> 
>>"Walter" <walter@digitalmars.com> wrote in message
>>news:ab426r$310j$3@digitaldaemon.com...
>>
>>
>>>Null pointer dereferences should GP fault, not hang. Since the hardware
>>>
>>does
>>
>>>the check for free, there's no profit to adding it into the language.
>>>Remember, you can write exception handlers to catch GP fault exceptions.
>>>
>>But still... not every hardware does, and even then, I'd like to see
>>the message explaining what REALLY happened, and not just another cryptic
>>GP error "info".
>>
>>
> 
> 
> Yep. "Null pointer dereferenced at line #25: mynullpointer->DoSomething();"
> would be a thousand times more valuable than "MYDAPP.EXE caused a general
> protection fault at address 34EF:4FEC: read of address 0000:0000"...
> 
> 
> --
> Stijn
> OddesE_XYZ@hotmail.com
> http://OddesE.cjb.net
> _________________________________________________
> Remove _XYZ from my address when replying by mail
> 
> 

That would be a fantastic idea, but does D compile the source code line information in with the program? It would be nice if that were an option during compile time, and if you wanted that information (along with the added bloat) you would get nice error messages, perfect for debugging, then for memory-constrained apps you could leave that info out? Has this  been discussed yet?

"Jonathan Andrew" <jon@ece.arizona.edu> wrote in message news:3CD601AB.7030707@ece.arizona.edu...

> That would be a fantastic idea, but does D compile the source code line
> information in with the program? It would be nice if that were an option
> during compile time, and if you wanted that information (along with the
> added bloat) you would get nice error messages, perfect for debugging,
> then for memory-constrained apps you could leave that info out? Has this
>   been discussed yet?

Of course this should only happen in debug builds!

As for the line info... well, assertions do store it (try assert(false)),
so why not other exceptions that are inserted by the compiler?

"Russell Borogove" <kaleja@estarcion.com> wrote in message news:3CD5AEF0.5040404@estarcion.com...

> Can we get Walter to standardize an exception object
> to catch general protection faults? Then every developer
> could display the GPF to the user in the way they found
> most useful.

By the way, I wonder if all systems that D might get
ported to support GPF?.. =)

I disagree.  For one, some architectures (68K, Playstation 1, 6502) cannot generate hardware GP faults so such errors will go undetected.

I think it would be a valuable debugging tool to throw on dereference of null object references.  Obviously only in debug builds, or perhaps only in "extra debug" builds...?

In any case I see this as an implementation issue, not a core language issue.

Sean

"Walter" <walter@digitalmars.com> wrote in message news:ab426r$310j$3@digitaldaemon.com...
> Null pointer dereferences should GP fault, not hang. Since the hardware
does
> the check for free, there's no profit to adding it into the language. Remember, you can write exception handlers to catch GP fault exceptions.