By the following code i get a normal Access Violation.
My question is: why? Even if "f0" is null, the object must be
converted to Ref and there i check if the given object is null.

Here is the Code:
[code]
// Ref.d

struct Ref(T : Object) {
private:
	T _val;

public:
	@disable
	this();

	@disable
	this(typeof(null));

	@disable
	typeof(this) opAssign(typeof(null));

	this(T val) {
		assert(val !is null);

		this._val = val;
	}

	@property
	T get() {
		return this._val;
	}
}

mixin template TRef(T) {
	@property
	Ref!(T) getRef() {
		assert(this !is null);

		return Ref!(T)(this);
	}

	alias getRef this;
}

// main.d
class Foo {
private:
	string _val;

public:
	this() { }

	void Set(string val) {
		this._val = val;
	}

	void speak() const {
		writeln(this._val);
	}

	mixin TRef!(typeof(this));
}

void with_ref(Ref!(Foo) rf) {
	rf.get.speak();
}

void without_ref(Foo f) {
	f.speak();
}

void main() {
	Foo f0; // f0 is null

	with_ref(f0); // converting with alias this. But what if f0 is
null?

	Foo f1 = new Foo();
	f1.Set("Foo!");

	with_ref(f1);
	without_ref(f1);

	readln();
}
[/code]

On Friday, 27 April 2012 at 16:36:04 UTC, Namespace wrote:
> By the following code i get a normal Access Violation.
> My question is: why? Even if "f0" is null, the object must be
> converted to Ref and there i check if the given object is null.

When trying to convert f0 to Ref, the compiler has to look in the
vtable for the getRef function. The vtable is in a nonsensical
place when the class reference is null, and thus it bails out.

Solution: mark getRef as final.

On Friday, 27 April 2012 at 16:49:49 UTC, Simen Kjaeraas wrote:
> On Friday, 27 April 2012 at 16:36:04 UTC, Namespace wrote:
>> By the following code i get a normal Access Violation.
>> My question is: why? Even if "f0" is null, the object must be
>> converted to Ref and there i check if the given object is null.
>
> When trying to convert f0 to Ref, the compiler has to look in the
> vtable for the getRef function. The vtable is in a nonsensical
> place when the class reference is null, and thus it bails out.
>
> Solution: mark getRef as final.

Great, thank you for reply, it works :).
It is maybe possible, that I get another error output as "null this"?
Maybe an assert or something else?

On Friday, 27 April 2012 at 16:57:52 UTC, Namespace wrote:
> On Friday, 27 April 2012 at 16:49:49 UTC, Simen Kjaeraas wrote:
>> On Friday, 27 April 2012 at 16:36:04 UTC, Namespace wrote:
>>> By the following code i get a normal Access Violation.
>>> My question is: why? Even if "f0" is null, the object must be
>>> converted to Ref and there i check if the given object is null.
>>
>> When trying to convert f0 to Ref, the compiler has to look in the
>> vtable for the getRef function. The vtable is in a nonsensical
>> place when the class reference is null, and thus it bails out.
>>
>> Solution: mark getRef as final.
>
> Great, thank you for reply, it works :).
> It is maybe possible, that I get another error output as "null this"?
> Maybe an assert or something else?

Now we're delving into some deep magic of the compiler. In non-release builds, the compiler adds a pre-function invariant, which is called before the function is called. This invariant contains the equivalent of assert(this !is null, "null this");, and this is what you run into.

There's currently no way to get rid of this but to compile for release, in which case your own assert also goes out the window.

On Friday, 27 April 2012 at 17:08:43 UTC, Simen Kjaeraas wrote:
> On Friday, 27 April 2012 at 16:57:52 UTC, Namespace wrote:
>> On Friday, 27 April 2012 at 16:49:49 UTC, Simen Kjaeraas wrote:
>>> On Friday, 27 April 2012 at 16:36:04 UTC, Namespace wrote:
>>>> By the following code i get a normal Access Violation.
>>>> My question is: why? Even if "f0" is null, the object must be
>>>> converted to Ref and there i check if the given object is null.
>>>
>>> When trying to convert f0 to Ref, the compiler has to look in the
>>> vtable for the getRef function. The vtable is in a nonsensical
>>> place when the class reference is null, and thus it bails out.
>>>
>>> Solution: mark getRef as final.
>>
>> Great, thank you for reply, it works :).
>> It is maybe possible, that I get another error output as "null this"?
>> Maybe an assert or something else?
>
> Now we're delving into some deep magic of the compiler. In non-release builds, the compiler adds a pre-function invariant, which is called before the function is called. This invariant contains the equivalent of assert(this !is null, "null this");, and this is what you run into.
>
> There's currently no way to get rid of this but to compile for release, in which case your own assert also goes out the window.


I see, too bad.
What could i do if i'm in release mode and will throw such error message?

I read about "collectExceptionMsg". Maybe that is a possible solution to catch Access Violations?

On Friday, April 27, 2012 19:38:34 Namespace wrote:
> I read about "collectExceptionMsg". Maybe that is a possible solution to catch Access Violations?

Access violations / segfaults aren't exceptions. They're OS signals. You can't catch them.

- Jonathan M Davis

On Friday, 27 April 2012 at 17:47:48 UTC, Jonathan M Davis wrote:
> On Friday, April 27, 2012 19:38:34 Namespace wrote:
>> I read about "collectExceptionMsg". Maybe that is a possible
>> solution to catch Access Violations?
>
> Access violations / segfaults aren't exceptions. They're OS signals. You can't
> catch them.
>
> - Jonathan M Davis

I forget...
But it should me possible to catch the "null this" message.

On Friday, 27 April 2012 at 17:51:13 UTC, Namespace wrote:
> On Friday, 27 April 2012 at 17:47:48 UTC, Jonathan M Davis wrote:
>> On Friday, April 27, 2012 19:38:34 Namespace wrote:
>>> I read about "collectExceptionMsg". Maybe that is a possible
>>> solution to catch Access Violations?
>>
>> Access violations / segfaults aren't exceptions. They're OS signals. You can't
>> catch them.
>>
>> - Jonathan M Davis
>
> I forget...
> But it should me possible to catch the "null this" message.

That does what i wanted. Thank you two. :)

static this() {
	onAssertErrorMsg(__FILE__, __LINE__, "Object is null!");
}

On Friday, 27 April 2012 at 18:01:55 UTC, Namespace wrote:
> On Friday, 27 April 2012 at 17:51:13 UTC, Namespace wrote:
>> On Friday, 27 April 2012 at 17:47:48 UTC, Jonathan M Davis wrote:
>>> On Friday, April 27, 2012 19:38:34 Namespace wrote:
>>>> I read about "collectExceptionMsg". Maybe that is a possible
>>>> solution to catch Access Violations?
>>>
>>> Access violations / segfaults aren't exceptions. They're OS signals. You can't
>>> catch them.
>>>
>>> - Jonathan M Davis
>>
>> I forget...
>> But it should me possible to catch the "null this" message.
>
> That does what i wanted. Thank you two. :)
>
> static this() {
> 	onAssertErrorMsg(__FILE__, __LINE__, "Object is null!");
> }

Sorry for triple post. I was too early. I get the Message "object is null" any time, with, and without thrown asserts.