Hi Crypto,
On Sun, Mar 1, 2015 at 3:32 AM, Crypto Compress <
cryptocompr...@googlemail.com> wrote:
> sorry for the late answer. My point is about throwing exceptions
> (assert.exceptions=1). I think it is wrong to allow to change code-flow by
> ini-setting and in current context it is wrong to throw exceptions
> altogether. Let's assume this code example in dev-mode with exceptions:
>
> class BankAccount {
> function Add($amount) {
> assert($amount > 0);
> // ... code block ...
> }
> }
>
> Now the programmer implementing "code block" to gracefully handle $amount
> > 0 has a problem. There is no way to (Unit)test failing path on
> development machine. Code after assertion is never called for failing
> contitions. What to do? Delete assertion is out of question. Disable
> zend.assertions on development machine seems to be the wrong way too. The
> only way to handle this is to disable exceptions (assert.exceptions=0) so
> expected code flow is restored. This, if allowed to be changed, should be
> at least the default.
>
> IMO ability to run and test code broadly outweighs "provides stacktrace by
> default" argument and for some reason i fear assert.exceptions=1 will be
> the only case soon.
>
I understand that removing assert conditions may seem to increase bugs in
code.
Wrong usage of assertion actually creates bugs. I agree.
However, assertion is not for production checks, but development time
checks.
Code example you're presented requires "caller" to make sure "$amount > 0"
condition
is met. Unit tests has to make sure "$amount > 0" condition is kept without
assertion.
Assertion (as well as DbC) helps to make sure if conditions/expectations of
"callee"
are fulfilled by "caller". Since caller must fulfill condition in the first
place, removing
assertions should not be problem under production environment and
production
codes execute faster.
Under structured programming, developers tend error condition check
responsibility
to "callee", just like your example. Use of assertion is DbC style
programming
which forces error condition checks to "caller". It changes why of thinking
and
these changes may be difficult to adopt for some developers, but the basic
idea is simple enough to be understood by all developers. I hope.
What good about DbC is it can achieve both robust development and faster
execution at the same time if it is used _properly_. I understand your
concern.
Developers must think what/where is the error condition check
responsibility.
Without this, the result can be fatal. Even if assertion/DbC has cons, its
pros
outweigh cons, IMHO.
Assertion/DbC
- Promotes caller to validate inputs. Input validation is the most
important for secure code.
- Underlying simple APIs that are called many times can omit various
condition checks in production. (Faster execution)
- Prevents wrong usage of API during development by assert failure.
- Makes developers to think where/how to implement "defense in depth"
properly. (Since no assertion checks in production, developers have to
think where/how to implement additional systematic defense in their code.
This is good for better security.)
I fully agree that users can misuse. We must make effort that users
understand
proper usage and idea behind assertions/DbC.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
