Program logic bugs vs input/environmental errors

[via Digitalmars-d]

On Saturday, 1 November 2014 at 15:02:53 UTC, H. S. Teoh via 
Digitalmars-d wrote:
> I never said "component" == "process". All I said was that at 
> the OS
> level, at least with current OSes, processes are the smallest 
> unit
> that is decoupled from each other. If you go below that level of
> granularity, you have the possibility of shared memory being 
> corrupted
> by one thread (or fibre, or whatever smaller than a process) 
> affecting
> the other threads. So that means they are not fully decoupled, 
> and the
> failure of one thread makes all other threads no longer 
> trustworthy.

This is a question of probability and impact. If my Python 
program fails unexpectedly, then it could in theory be a bug in a 
c-library, but it probably is not. So it is better to trap it and 
continue.

If D provides bound checks, is a solid language, has a solid 
compiler, has a solid runtime, and solid libraries… then the same 
logic applies!

If my C program traps on divison by zero, then it probably is an 
unlucky incident and not a memory corruption issue. So it is 
probably safe to continue.

If my program cannot find a file, it MIGHT be a kernel issue, but 
it probably isn't. So it safe to continue.

If my critical state is recorded by a wall built on transactions 
or full blown event logging, then it is safe to continue even if 
my front might suffer from memory corruption.

You need to consider:

1. probability (what is the most likely cause of this signal?)

2. impact (do you have insurance?)

3. alternatives (are you in the middle of an air fight?)