dereferencing null

Sandeep Datta datta.sandeep at gmail.com
Sat Mar 3 18:53:53 PST 2012


> 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.


More information about the Digitalmars-d mailing list