• Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> Jun 03 2014

Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:

On Tue, 03 Jun 2014 21:11:52 +0200
Andre via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 As I known that assertions are only for unittest purposes I hoped,
 if I use enforce, this statements will not be removed in release build
 and will still be executed - wrong.

 I see, the idea of contracts in D differs to the idea of contracts
 e.g. in Java (http://c4j-team.github.io/C4J/
 Here contracts are used for unittest but also for the productive code
 in release builds.


I don't know what C4J does, but the entire purpose of having in and out
contracts in D is to support Design by Contract, so they're intended to catch
bugs where the "contract" of a function is violated (i.e. where it requires
that the input satisfy certain criteria and guarantees certain criteria for
its output). It has nothing to do with error handling whatsoever. If anything,
design by contract is the antithesis of error handling, because it's
considered an outright bug if a contract is violated. As such, it really
doesn't make sense to use the in or out blocks for anything other than
assertions.

And honestly, I don't see how you would gain anything if you could. Aside from
virtual functions, there is no difference between asserting at the beginning
of a function or in the in block, and there is no difference between asserting
in the out block and asserting in a scope(success) statement which is put at
the beginning of the function. The only place where the in and out blocks
actually gain you anything is that in a virtual function their success or
failure is effectively &&ed or ||ed with those of the other virtual functions
in the inheritance tree (because the in contracts only have to be as strict as
the contracts in the most derived function, and the out contracts have to be
as strict as the contracts in all of the virtual functions in the inheritance
tree). It's that extra bit of logic for classes where the runtime catches and
ignores AssertErrors where appropriate that actually makes it so that the in
and out blocks actually buy you anything.

And since none of that would actually apply to exceptions, I don't see how
using in and out blocks would actually buy you anything when using exceptions.
As it is, it doesn't buy you much when using assertions.

- Jonathan M Davis