I'd be tempted to go way back to the very root of the problem starting with Tony Hoare again. Eliminate null as a possibility. That's a whole other subject, though.

On Friday, 27 March 2015 at 14:39:36 UTC, Shammah Chancellor wrote:
> All the languages you mention run in a VM.   In the case of a systems language like D, the operation system itself is intercepting the reference to invalid memory and sending a SIGSEG to the process.  The default handler causes the process to immediately terminate.   Having the D runtime do something different in the SIGSEG handler by default would be bad form.
>
> -Shammah

Most VM use segfault trapping for null check.

On Thu, Mar 26, 2015 at 9:13 PM, deadalnix via Digitalmars-d < digitalmars-d@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.
>

On Saturday, 28 March 2015 at 22:53:54 UTC, Timothee Cour wrote:
> 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).

In that case, it should be an Error, not an Exception, since it'll be disabled in release mode.

Especially working with fibers, ability to catch NullPointerException is more important. If a NullPointerException is caught , only one fiber terminates, otherwise, the whole server crashes.

If the server is something like webserver(stateless),multi-process is ok. But I am aiming to develope a mmorpg server, it is stateful, so it is not allowed to crash entirely.

Maybe the solution is to make use of  a script engine (such as lua), but the benefit of choosing dlang is lost.

On Tuesday, 31 March 2015 at 03:58:33 UTC, zhmt wrote:
> Especially working with fibers, ability to catch NullPointerException is more important. If a NullPointerException is caught , only one fiber terminates, otherwise, the whole server crashes.
>
> If the server is something like webserver(stateless),multi-process is ok. But I am aiming to develope a mmorpg server, it is stateful, so it is not allowed to crash entirely.
>
> Maybe the solution is to make use of  a script engine (such as lua), but the benefit of choosing dlang is lost.

I argue that instead of catching NullPointerExceptions, you should make them never happen. This is where Option types come in. Rather than using T*, use an Option!T and force yourself to always check for null gracefully. Also use Some!T (a.k.a NotNull) and get classes and pointers which are verified via contracts that they are not null.

I have already implemented such a thing here.

https://w0rp.com/project/dstruct/dstruct/option/

If you don't like it, you can always implement a similar thing yourself.

Now at this point you might wish for this to gain some benefits from being a language feature. I think I will agree, but who knows if that will ever happen.

I should say Option!(T*) and Some!(T*), as that's what is.

On Tuesday, 31 March 2015 at 07:48:08 UTC, w0rp wrote:

> I argue that instead of catching NullPointerExceptions, you should make them never happen. This is where Option types come in. Rather than using T*, use an Option!T and force yourself to always check for null gracefully. Also use Some!T (a.k.a NotNull) and get classes and pointers which are verified via contracts that they are not null.
>
> I have already implemented such a thing here.
>
> https://w0rp.com/project/dstruct/dstruct/option/
>
> If you don't like it, you can always implement a similar thing yourself.
>
> Now at this point you might wish for this to gain some benefits from being a language feature. I think I will agree, but who knows if that will ever happen.

Maybe this a good direction.

A pointer or reference is replaced by a struct (a pointer holder?), and the struct will check if the pointer is null.

It is a good idea, I could check the pointer myself now, and stopping worring about server crashing, that's enough.

Excellent job, Thank you!

On Friday, 27 March 2015 at 11:17:54 UTC, Steven Schveighoffer wrote:
> Please note, this is NOT a null pointer exception, it's a segfault exception. This can happen with corruption (absolutely should not continue) as well as forgetting to initialize a variable (dangerous if not handled correctly, but still feasible to continue). It may not be as black and white as if it's a null pointer that was dereferenced or not. I highly recommend terminating the process.

A segfault can also be I/O error on a mmap'ed file, so termination is not always the right action.

On Tuesday, 31 March 2015 at 08:17:29 UTC, zhmt wrote:
> On Tuesday, 31 March 2015 at 07:48:08 UTC, w0rp wrote:
>
>> I argue that instead of catching NullPointerExceptions, you should make them never happen. This is where Option types come in. Rather than using T*, use an Option!T and force yourself to always check for null gracefully. Also use Some!T (a.k.a NotNull) and get classes and pointers which are verified via contracts that they are not null.
>>
>> I have already implemented such a thing here.
>>
>> https://w0rp.com/project/dstruct/dstruct/option/
>>
>> If you don't like it, you can always implement a similar thing yourself.
>>
>> Now at this point you might wish for this to gain some benefits from being a language feature. I think I will agree, but who knows if that will ever happen.
>
> Maybe this a good direction.
>
> A pointer or reference is replaced by a struct (a pointer holder?), and the struct will check if the pointer is null.
>
> It is a good idea, I could check the pointer myself now, and stopping worring about server crashing, that's enough.
>
> Excellent job, Thank you!

It's a commmon pattern now. I think I personally copied the way Scala does it. I used contracts for the checks, and my hope is that with the contracts off and the right optimisations, you can get roughly the same code generated as if you didn't use the option types at all.

I think my inclusion of opApply on the Option type was a mistake. I will probably remove that in future. I have a function for creating a range from them anyway. Feel free to try my types if you like. I haven't tested them enough to figure out how effective they are, or there are any bugs I missed.