Why dont dlang check NullPointer?

Timothee Cour via Digitalmars-d digitalmars-d at puremagic.com
Sat Mar 28 15:53:44 PDT 2015


On Thu, Mar 26, 2015 at 9:13 PM, deadalnix via Digitalmars-d <
digitalmars-d at puremagic.com> wrote:

> On Friday, 27 March 2015 at 03:59:30 UTC, zhmt wrote:
>
>>
>>> The best way to do that is to separate the server modules into
>>> independent processes. Then if one crashes, the others keep running without
>>> fear of corruption.
>>>
>>> So instead of server modules, try doing mini servers that communicate
>>> with the main server. This is how a lot of newer programs are written
>>> because of the reliability and security benefits it offers.
>>>
>>
>> But this will make the developement more difficult for me, or not
>> acceptable.
>>
>> Is there any other ways?
>>
>
> http://www.deadalnix.me/2012/03/24/get-an-exception-from-a-
> segfault-on-linux-x86-and-x86_64-using-some-black-magic/
>
> There is a hook in the runtime to enable this if you want.
>


You post only mentions linux, not OSX (and a comment showed:

"According to several people I talked to, it is possible to do a similar
stuff on BSD like systems (including OSX). But I’m really not a specialist
of such platforms, so I can’t really explain you how."

Could anyone post such a solution?

If there's no easy way to do it, there should be a way (eg a compiler
option) to throw an exception on null pointer access. Even if it's unsafe,
it would help for debugging (eg printing relevant application specific
context). This is made worse by the fact that stacktraces are not very
helpful on OSX (eg line number often missing etc).



>
> BUT, null pointer exception or not, Adam is right. Have your stuff run in
> multiple process that you can restart. This is more reliable, this is more
> secure, this is easier to update without downtime, and so on... This is far
> superior solution for server stuff.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20150328/be7d0186/attachment.html>


More information about the Digitalmars-d mailing list