The extent of trust in errors and error handling

[Ali Çehreli via Digitalmars-d]

On 02/05/2017 08:49 AM, Chris Wright wrote:
 > On Sat, 04 Feb 2017 23:48:48 -0800, Ali Çehreli wrote:
 >> Doesn't change what I'm saying. :) For example, RangeError may be thrown
 >> due to a rogue function writing over memory that it did not intend to.
 >> An index 42 may have become 42000 and that the RangeError may have been
 >> thrown. Fine. What if nearby data that logf depends on has also been
 >> overwritten? logf will fail as well.
 >
 > I can't count on an error being thrown, so I may as well not run my
 > program in the first place.

Interesting. That's an angle I hadn't considered.

 > That's the only defense. It's only wishful
 > thinking that my program's data hasn't already been corrupted by the GC
 > and the runtime but in a way that doesn't cause an Error to be thrown.

Yeah, all bets are off when memory is shared by different actors as is 
the case for conventional CPUs.

Thanks everyone who contributed to this thread. I learned more. :)

Ali