www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Null references and access violation

reply Bauss <jj_1337 live.dk> writes:
Can someone riddle me this, why D gives an access violation 
instead of ex. a null reference exception?

Like let's say you have a field that's a class and you forget to 
give it a value. Now that will cause an access violation, but 
generally access violations are an indication that you're program 
has reached a nasty state and can't be recovered. Hence why you 
cannot catch it by doing a normal catch block for "Exception", 
but has to do on "Throwable" (Idk if "Error" works for?) Now 
that's a problem, because in that particular case the program may 
still work without being in an unrecoverable state.

Of course it can be resolved by catching it, but what about 
actual unrecoverable access violations? You will be shadowing 
those too then.

This is especially a problem when you work with 3rd party 
libraries where you basically have no control over what happens.

Is there a way around this, to make thins like not assigning an 
instance to a class cause some null reference exception or is 
there a specific reason why it exactly throws an access violation 
error.
Sep 14 2016
next sibling parent Marco Leise <Marco.Leise gmx.de> writes:
Am Wed, 14 Sep 2016 16:52:19 +0000
schrieb Bauss <jj_1337 live.dk>:


 Can someone riddle me this, why D gives an access violation 
 instead of ex. a null reference exception?


Access violations cost exactly 0. Noone needs to do anything
extra for this check that isn't done by the CPU already. The
next step is an assertion (which I think is done in debug mode
when you call a method on a null object). That's still not
recoverable, just like out of memory situations in D.
Compare for example in-contracts, where you assert for
not-null. Those throw unrecoverable errors as well unless you
turn them from

  assert(obj !is null);

into 

  if (obj is null) throw new NullPointerException();

(And that's what the compiler in its current state would
probably insert for you on every access to the object.)

D is somewhat consistent in making null pointers and other
contracts/assertions fatal errors that end program execution.
In other words: Everything that's a fault in the program logic
gives you a rather harsh exit, while unforseeable situations
like network errors or incorrect user input are handled by
exceptions. Walter mentioned that when a program is run inside
a debugger, access violations are the easiest problem for the
debugger, while D exceptions on Linux are not as easy to
break on.

I understand the sentiment though. I've seen a Karaoke
software throw exceptions because no item was selected in a
list box. If that was an access violation you could not
have acknowledged the OutOfBounds/NullPointer message, selected
an item and continued. Depending on how and where the software
is used, one or the other is a better default.

We have had some interesting proposals on not-null references
(as NullPointerExceptions are seen as a mistake in retrospect
by language designers [citation needed]) and "remembering"
what line of code has safe access to the object. E.g.
everything in "if (obj) { ... }" can safely access the object.

-- 
Marco
Sep 14 2016
prev sibling next sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wednesday, September 14, 2016 16:52:19 Bauss via Digitalmars-d wrote:

 Can someone riddle me this, why D gives an access violation
 instead of ex. a null reference exception?

 Like let's say you have a field that's a class and you forget to
 give it a value. Now that will cause an access violation, but
 generally access violations are an indication that you're program
 has reached a nasty state and can't be recovered. Hence why you
 cannot catch it by doing a normal catch block for "Exception",
 but has to do on "Throwable" (Idk if "Error" works for?) Now
 that's a problem, because in that particular case the program may
 still work without being in an unrecoverable state.

 Of course it can be resolved by catching it, but what about
 actual unrecoverable access violations? You will be shadowing
 those too then.

 This is especially a problem when you work with 3rd party
 libraries where you basically have no control over what happens.

 Is there a way around this, to make thins like not assigning an
 instance to a class cause some null reference exception or is
 there a specific reason why it exactly throws an access violation
 error.


Dereferencing null is generally considered to be a program bug and thus
should be treated as unrecoverable - just like failed assertions are
considered to be unrecoverable, which is why they throw AssertErrors and not
AssertExceptions. So, if we were going to have null-checks built-in, then
we'd throw something like NullDereferencingError and not NullException.
However, Walter's stance on this is that the CPU already does the null
checks for you - that's why you get a segfault on *nix or an access
violation on Windows. The CPU checked. Any additional checks would therefore
just be unnecessary overhead.

If you don't want to have problems with dereferencing null pointers or
references, then check for null in the cases where a pointer or reference
might be null.

- Jonathan M Davis
Sep 14 2016
parent pineapple <meapineapple gmail.com> writes:
On Wednesday, 14 September 2016 at 18:36:46 UTC, Jonathan M Davis 
wrote:

 If you don't want to have problems with dereferencing null 
 pointers or references, then check for null in the cases where 
 a pointer or reference might be null.

 - Jonathan M Davis


Writing your functions that disallow null inputs like `fn(int* 
arg) in{assert(arg !is null);} body{ ... }` is readable, concise, 
and in my opinion a generally elegant solution to the problem.
Sep 14 2016
prev sibling parent Kagamin <spam here.lot> writes:
http://forum.dlang.org/post/atxyappczlyvqyalvwzw forum.dlang.org
Sep 16 2016