dereferencing null

Martin Nowak dawg at dawgfoto.de
Tue Mar 6 08:49:19 PST 2012


On Tue, 06 Mar 2012 12:14:56 +0100, Don Clugston <dac at nospam.com> wrote:

> 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.
>
Yeah, it's true for FPU traps. You need signals+longjmp to handle them.
Though with SEH you shouldn't forget to fninit before continuing or your
FPU stack might overflow.


More information about the Digitalmars-d mailing list