dereferencing null

[Don Clugston]

On 04/03/12 04:34, Walter Bright wrote:
> 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).

Responding to traps is one of the very few examples I know of, where 
Windows got it completely right,
and *nix got it absolutely completely wrong. Most notably, the hardware 
is *designed* for floating point traps to be fully recoverable. It makes 
perfect sense to catch them and continue.
But unfortunately the *nix operating systems are completely broken in 
this regard and there's nothing we can do to fix them.