Program logic bugs vs input/environmental errors

[Johannes Pfau via Digitalmars-d]

Am Thu, 09 Oct 2014 13:10:34 +0000
schrieb "Dicebot" <public at dicebot.lv>:

> On Wednesday, 8 October 2014 at 03:20:21 UTC, Walter Bright wrote:
> >> Can we at least agree that Dicebot's request for having the 
> >> behaviour of
> >> inadvisable constructs defined such that an implementation 
> >> cannot randomly
> >> change behaviour and then have the developers close down the 
> >> corresponding
> >> bugzilla issue because it was the user's fault anyway is not 
> >> unreasonable by
> >> definition because the system will not reach a perfect state 
> >> anyway, and then
> >> retire this discussion?
> >
> > I've been working with Dicebot behind the scenes to help 
> > resolve the particular issues with the code he's responsible 
> > for.
> >
> > As for D, D cannot offer any guarantees about behavior after a 
> > program crash. Nor can any other language.
> 
> Just wanted to point out that resulting solution (== manually 
> switching many of contracts to exceptions from asserts) to me is 
> an unhappy workaround to deal with overly opinionated language 
> and not actually a solution. I still consider this a problem.

A point which hasn't been discussed yet:

Errors and therefore assert can be used in nothrow functions. This is a
pita for compilers because it now can't do certain optimizations. When
porting GDC to ARM we started to see problems because of that (can't
unwind from nothrow functions on ARM, program just aborts). And now we
therefore have to worsen the codegen for nothrow functions because of
this.

I think Walter sometimes suggested that it would be valid for a
compiler to not unwind Errors at all (in release mode), but simply kill
the program and dump a error message. This would finally allow us to
optimize nothrow functions.