Program logic bugs vs input/environmental errors

H. S. Teoh via Digitalmars-d digitalmars-d at puremagic.com
Mon Oct 6 20:51:10 PDT 2014


On Mon, Oct 06, 2014 at 07:55:23PM -0700, Walter Bright via Digitalmars-d wrote:
> On 10/6/2014 10:09 AM, Dicebot wrote:
> >It is only in undefined state because language handles Errors that
> >way. At the point of throwing the Error state was perfectly defined
> >and 100% recoverable.  This is the typical case for assertion failure
> >in contract - it detects some program flaw like inability to handle
> >specific data combination from other process but it does not mean
> >memory is corrupted or program is inherently broken. Just killing the
> >fiber and continuing with other requests (which don't trigger that
> >unexpected code path) is absolutely fine unless compiler kicks in and
> >optimizes something away in surprising fashion.
> 
> What you're describing sounds like using asserts to validate input
> data.  This is not what asserts are for.

Using assertions in contracts in D currently has some design issues, one
of the foremost being that in-contracts of derived classes are allowed
to be more relaxed than base classes, which means that the effective
contract is (baseClassContract || derivedClassContract).  However, since
in-contracts are allowed to be arbitrary statements, the only way to
implement this is to catch AssertErrors and continue running if at least
one of the contracts didn't assert. But that means we're technically in
an undefined state after that point. :-(

(If the in-contract calls a nothrow function that asserts, for example,
dtors may have been skipped, cleanups not performed, etc., and yet we
blindly barge on because the other contract didn't assert.)


T

-- 
LINUX = Lousy Interface for Nefarious Unix Xenophobes.


More information about the Digitalmars-d mailing list