C/C++ style Crashes?

[Sebastian Biallas]

Alexander Panek wrote:
> Sebastian Biallas wrote:
>> Jon Grant wrote:
>>> Hi
>>> Just having a look at the D language.
>>> Does D still let the programmer allocate memory, cast addresses and
>>> read/write
>>> direct address space as we can from C/C++?
>>>
>>> I'd like to know if it solves this problem, Java and C# don't allow
>>> such access.
>>
>> An important point is that this doesn't solve this problem either. Ok,
>> you get an exception instead of some "undefined behaviour", which is
>> somehow better when debugging, but:
>>
>> It just doen't solve the problem that you have a bug in your program in
>> the first place. Reread that sentence.
> 
> Exceptions can be handled at runtime, still. try (to) catch it and there
> you go. :)

So, how exactly do you /handle/ an exception which "should not be there"?

>> Getting an unexpected exception in a shipped application is a huge bug.
> 
> That's why you always /test/ everything so good, that you just don't get
> unexpected exceptions.

Well, so you shouldn't need exceptions at all for array handling, right?
(Except for debugging, where they really help)

> What's the huge problem with exception handlers? 

There is nothing wrong which exception handlers for handling exceptions
that the programmer thought of (file-not-found, io-error, etc).

But things like ArrayOutOfBounds, NullPointer and CastErrorException are
bugs in the program (usually). Often they get thrown at places where
there's no appropriate catch around or transaction logic so they get
caught by some high level "catch everything".

So what to do now? The program is now in an unstable state.
And even if you catch the Exception on the right place: The Exception
should never have been thrown. There is a bug, and the bug is not
necessarily at the place where the exception was thrown -- the program
might have been in an inconsistent state for hours.

> They worked for me
> pretty well so far to avoid a unhandled exceptions that just terminate
> the program.

It would be even better if the compiler could prove at compiler-time,
that there are no OutOfBound, NullPointer and CastExceptions possible.

While this is hard for ArrayOutOfBounds, there are quite easy ways for
avoiding NullPointer and CastExceptions at all. In the language Nice[1]
they do this as follows:

NullPointer: They have different types for pointers that can be null
(?Type) and pointer that can't (Type). You can't dereference a ?Type
variable.

So, let's say we have

void foo(?Type t)
{
	// we want to dereference t
	if (t != null) {
		// now the compiler "magically" converts t to type Type
		t.doSomething();
	}
}

TypeCasts: You don't cast with a cast-operator, but with a
instance-of-expression:

void bar(A a)
{
	if (a instanceOf B) {
		// now a is of type B, no need to cast
	}
}

I haven't used this language yet, but these are certainly, well, nice
features :)

[1] http://nice.sf.net