Program logic bugs vs input/environmental errors

via Digitalmars-d digitalmars-d at puremagic.com
Fri Oct 3 12:05:49 PDT 2014


On Friday, 3 October 2014 at 17:33:33 UTC, Piotrek wrote:
> That depends on design (logic). Ever heard of this?
> http://www.reddit.com/r/programming/comments/1ax0oa/how_kdes_1500_git_repositories_almost_were_lost/

How is not having redundant storage, logging or backup related to 
this?

This is a risk assessment scenario: «What are we willing to loose 
compared to what it costs to mitigate the risks by investing in 
additional resources?»

> A logic error would be a case when you think you are running a 
> garage but suddenly you noticed your stuff is selling meals and 
> is wearing chef's uniforms.

But it is a business decision whether it is better to take 
amazon.com off the network for a week or just let their search 
engine occasionally serve food instead of books as search 
results. Not an engineering decision.

It is a business decision whether it is better for a game to 
corrupt 1% of user accounts and let customer support manually 
build them back up than to take the game off the network until 
the problem is fixed. You would probably have heavier load on 
customer support and loose more subscriptions by taking the game 
off the network than giving those 1% one year of free game play 
as a compensation.

If you have a logic error in a functional routine, it is local. 
It might not matter, it might be expected.

Logic errors do not imply memory corruption.
Memory corruption does not imply that exceptions are thrown.

Even if memory corruption would lead to exceptions being thrown 
in 30% of the cases, you'd still have 70% of cases where memory 
corruption goes undetected. So if that is a concern, you need to 
focus elsewhere.

You have to think about this in probabilistic terms and relate it 
to business decisions.

Defining thresholds for acceptable reliability is not an 
engineering decision. An engineering decision is to use isolates, 
Erlang, Haskell etc to achieve the thresholds set as acceptable 
reliability/quality viewed from a business point of view.


More information about the Digitalmars-d mailing list