class A
	{
		void test()
		{
			writeln("test");
		}
	}

	try
	{
		A a = null;
		a.test();
	}catch(Throwable t)
	{
		writeln(t.msg);
	}


The code above will not print a exception message, but crashes instead.


I dont think this a good choice for most scenes. For example,I developed many modules in my server, and add a new module now. If null exception happens, I hope the server continue running, not crash. If the server continue running, the functions offered by old modules can be used by users, only the new module stop serving.



In short words, I want to catch something like NullPointerException.

Is this possible?

On Friday, 27 March 2015 at 03:46:49 UTC, zhmt wrote:
> The code above will not print a exception message, but crashes instead.

It actually will throw on Windows and can be tricked into it on Linux; it is an operating system thing more than a language thing.

But...

> If null exception happens, I hope the server continue running, not crash. If the server continue running, the functions offered by old modules can be used by users, only the new module stop serving.

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.

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

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.

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 Friday, 27 March 2015 at 04:13:01 UTC, deadalnix 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.
>
> 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.

multi-process means crashes are isolated by process, but isolated by thread may be more handy.

For example , this feature is suported by java c# lua, ie.

This can make dlang app developed by most developers more reliable.

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

I will try this black magic,Thanks.

On Friday, 27 March 2015 at 03:46:49 UTC, zhmt wrote:
> 	class A
> 	{
> 		void test()
> 		{
> 			writeln("test");
> 		}
> 	}
>
> 	try
> 	{
> 		A a = null;
> 		a.test();
> 	}catch(Throwable t)
> 	{
> 		writeln(t.msg);
> 	}
>
>
> The code above will not print a exception message, but crashes instead.
>
>
> I dont think this a good choice for most scenes. For example,I developed many modules in my server, and add a new module now. If null exception happens, I hope the server continue running, not crash. If the server continue running, the functions offered by old modules can be used by users, only the new module stop serving.
>
>
>
> In short words, I want to catch something like NullPointerException.
>
> Is this possible?

GCC has the switch -fno-non-call-exceptions, but not sure if GDC does. You could ask in the gdc forum?

zhmt:

> In short words, I want to catch something like NullPointerException.
>
> Is this possible?

One solution is to add null tests to D in nonrelease mode. A better solution is to modify D to remove all or most chances of dereferencing null pointers and class references.

Bye,
bearophile

On 3/27/15 12:13 AM, deadalnix 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.
>
> 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.

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.

As for the original question (why does D do this?), it's because the system ALREADY catches null pointer access. To add additional checks would slow down the system. And as you can see, you can hook these mechanisms to actually throw an exception, but this is a relatively recent development.

In addition, as I mentioned, a seg fault can occur for a number of reasons, and D takes the position that you really should just terminate the process if this happens.

The reason using multiple processes is more secure and reliable is because a rogue thread (one that has segfaulted because of a memory corruption error) can corrupt data in all your other threads. A separate process cannot.

-Steve

On 2015-03-27 05:34:59 +0000, zhmt said:

> On Friday, 27 March 2015 at 04:13:01 UTC, deadalnix 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.
>> 
>> 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.
> 
> multi-process means crashes are isolated by process, but isolated by thread may be more handy.
> 
> For example , this feature is suported by java c# lua, ie.
> 
> This can make dlang app developed by most developers more reliable.

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