C/C++ style Crashes?

Alexander Panek a.panek at brainsware.org
Fri Jan 12 09:34:26 PST 2007


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 - maybe also automatically sending 
a bug report to the developers or the IT department of a company. This 
depends on what kind of software you write/use(libraries). Apart from 
that, D has this neat scope(fail) thing, that will cover almost all 
circumstances, except segmentation faults .. ;)

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

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

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

> 
>> 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. One way 
could be, to use a debugger that reflects the whole application 
execution (there is such a debugger for Java, that records literally 
everything).

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

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

> 
> I haven't used this language yet, but these are certainly, well, nice
> features :)
> 
> [1] http://nice.sf.net

Best regards,
Alex



More information about the Digitalmars-d mailing list