dereferencing null

[Walter Bright]

On 3/3/2012 6:53 PM, Sandeep Datta wrote:
>> It's been there for 10 years, and turns out to be a solution looking for a
>> problem.
>
> I beg to differ, the ability to catch and respond to such asynchronous
> exceptions is vital to the stable operation of long running software.
>
> It is not hard to see how this can be useful in programs which depend on plugins
> to extend functionality (e.g. IIS, Visual Studio, OS with drivers as plugins
> etc). A misbehaving plugin has the potential to bring down the whole house if
> hardware exceptions cannot be safely handled within the host application. Thus
> the inability of handling such exceptions undermines D's ability to support
> dynamically loaded modules of any kind and greatly impairs modularity.
>
> Also note hardware exceptions are not limited to segfaults there are other
> exceptions like division by zero, invalid operation, floating point exceptions
> (overflow, underflow) etc.
>
> Plus by using this approach (SEH) you can eliminate the software null checks and
> avoid taking a hit on performance.
>
> So in conclusion I think it will be worth our while to supply something like a
> NullReferenceException (and maybe NullPointerException for raw pointers) which
> will provide more context than a simple segfault (and that too without a core
> dump). Additional information may include things like a stacktrace (like
> Vladimir said in another post) with line numbers, file/module names etc. Please
> take a look at C#'s exception hierarchy for some inspiration (not that you need
> any but it's nice to have some consistency across languages too). I am just a
> beginner in D but I hope D has something like exception chaining in C# using
> which we can chain exceptions as we go to capture the chain of events which led
> to failure.

As I said, it already does that (on Windows). There is an access violation 
exception. Try it on windows, you'll see it.

1. SEH isn't portable. There's no way to make it work under non-Windows systems.

2. Converting SEH to D exceptions is not necessary to make a stack trace dump work.

3. Intercepting and recovering from seg faults, div by 0, etc., all sounds great 
on paper. In practice, it is almost always wrong. The only exception (!) to the 
rule is when sandboxing a plugin (as you suggested). Making such a sandbox work 
is highly system specific, and doesn't always fit into the D exception model (in 
fact, it never does outside of Windows).