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