Re: Null references and access violation

[Kagamin via Digitalmars-d]

http://forum.dlang.org/post/atxyappczlyvqyalv...@forum.dlang.org

Re: Null references and access violation

[pineapple via Digitalmars-d]

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.

Re: Null references and access violation

[Jonathan M Davis via Digitalmars-d]

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

Re: Null references and access violation

[Marco Leise via Digitalmars-d]

Am Wed, 14 Sep 2016 16:52:19 +
schrieb Bauss :

> 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

Null references and access violation

[Bauss via Digitalmars-d]

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.