C/C++ style Crashes?

[Alexander Panek]

Sebastian Biallas wrote:
> Alexander Panek schrieb:
>> Sebastian Biallas wrote:
>>>>> [...]
>>>>> 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"?
>>
>> One has to make sure to catch all "should not be there" exceptions, 
>> too (ideally). In the real world, of course, there can happen to be 
>> mistakes in the code, hidden bugs and what not else. But the fact is, 
>> that in most software, that is really fully tested, those happen very 
>> rarely and can be handled with special routines - 
> 
> By what routines?

The bug report possibility was one example.

> 
>> maybe also automatically sending a bug report to the developers or the 
>> IT department of a company. 
 > [...]
>>>>> 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)
>>
>> As soon as the amount of /dynamic/ data you have to handle grows, I 
>> don't think there's a way around using at least exceptions to stay safe.
> 
> I'm not sure I understand that sentence.

I'm just saying that you have to use proper exception handling, to stay 
error safe (not bug safe), as soon as (dynamic) data of variable length 
and kind is to be handled.

> 
> Maybe I should clearify my point:
> Exceptions are a nice way to handle unpredictable situations at runtime, 
> like an IO error. Java helps you even with this, when you use the 
> throw() specifier for your io-functions.

Exactly, that's what I mean.

> 
> But exceptions are IMHO a wrong way to handle /programming mistakes/. 
> Programming mistakes must be fixed by a programmer -- they can't be 
> fixed at runtime. It's just too late if a buggy program is running.

Of course. But a language only may /help/ to avoid programming mistakes. 
I don't think it's feasable to really restrict pointer usage like in the 
examples you brought up. But that's just me, I love pointers and what 
you can mess up with them. :)

>>> 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.
>>
>> This is, of course, not so good. But then again, you should design the 
>> software in a way that avoids such circumstances (yes, this is not 
>> possible in any cases, but in very much).
> 
> This is pretty much the answer you get from someone advocating C or C++ 
> if you ask him why a C or C++ program behaves in such an unpredictable 
> way ;)

Aww, got me there. ;)

> 
>>>> 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.
>>
>> AFAIK, D handles this as long as it's not dynamic data. As soon as 
>> array indexes, pointer arithmetic or other not so exotic things kick 
>> in, there's no way to determine what values/states there can be. 
> 
> You need a careful designed language for this. See e.g. SPARK (I haven't 
> used it yet).

Where 'careful' is the thing that splits the programmers community in 
two.. (safe/unsafe and such things). I don't really know SPARK, but I 
think D does a good job /already/, regarding 'safety'.

>>> 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();
>>>     }
>>> }
>>
>> How about:
>>
>> void foo ( Type t )
>> in {
>>     assert( t != null );
>> }
>> body {
>>     t.doSomething();
>> }
>>
>> I find this rather equal.
> 
> It is rather equal. The difference is not in the source code, the 
> difference is how you /can/ write this.
> 
> In Nice you just have this one possibility: If you want to dereference a 
> ?pointer, you have to test it against null -- otherwise it won't 
> compile. In other languages this test is optional (and even whether a 
> pointer can be null is not part of the language but of the 
> documentation. And documentation is often not available or wrong).

Hm. Then again, why not make it automatically: every pointer that is 
dereferenced gets a comparison to null before being used (imho better 
than explicitely typing if(t==null) all the time).

> 
> Of course you can write correct code in D and other languages. The point 
> is: In Nice the code is guaranteed to be correct regarding null-pointer 
> checks once it compiles! There is no need of a "style guide" for this 
> which will be ignored once the project reaches its deadline.
> 
>>> 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
>>>     }
>>> }
>>
>> What exactly does an instance-of-expression? Never seen this, actually.
> 
>     if (a instanceOf B) {
> 
> is the same as
> 
>     if (dynamic_cast<B>(a)) {  // in C++
> 
> or
> 
>     if (cast(B) a) { // in D

Mh, well. That's a matter of taste, I'd say. (IIRC, it was even proposed 
somewhen?)