[VOTE] Expectations View as Markdown

However I think it is pre
mature to vote on as there was (sorry) not explicit discussions about
it.

I haven't heard that from anyone else, the RFC is plenty old.

A couple of things are unclear. See the numerous questions in this thread.
I also do not like other things.

These don't seem like valid reasons to hold off progress.

zend.assertions:

Having a more general debug setting might be a good idea, but is outside of
the scope of this RFC.

assert.exceptions:

Delay isn't necessary, exceptions are not used by default, and there is
plenty of time for Engine Exceptions to make necessary changes.

Cheers
Joe

On Fri, Feb 20, 2015 at 2:55 PM, Crypto Compress <
cryptocompress@googlemail.com> wrote:

Am 20.02.2015 um 15:09 schrieb Nikita Popov:

On Fri, Feb 20, 2015 at 3:02 PM, Crypto Compress <
cryptocompress@googlemail.com mailto:cryptocompress@googlemail.com>
wrote:

    AssertionExceptions are not intended to be caught, they are
    intended to be seen, in a specific environment.


Joe, your argumentation is around how (not) to use exceptions. I
can see your point and it's valid.
My point is about not to implement exceptions at all.

If exceptions are not intended to be caught, they don't need to be
thrown (even if the context is different).
If exceptions are not thrown and not caught, we can use "error" in
dev and some easing severity (warning, zero cost nothing) in prod.

Freely adapted from Murphy: If assertion exception can be catched,
it will be even in production.

The point behind AssertionException is that
a) It will leave the scope where with the failed assertion immediately. A
warning would continue running the code, even though some precondition is
violated, which doesn't make sense.

Assumed context is wrong here.

• exception in development: error
• no exception in production: warning, zero cost nothing

Rephrased: A zero-cost non-existing exception would continue running the
code, ...

In a previous email you brought up the point if or not derive AssertionEx
from Exception. I argue that all child exception MUST BE derived from
Exception. Any exception to this is not an Exception. (my english is too
limited to explain this, sorry)

b) It can still be gracefully handled (unlike a fatal error). E.g. the

unit testing framework can catch it, so you can continue running all your
tests even if one causes an assertion failure.

Unit test frameworks do this already. No change here.

When Joe says "not intended to be caught" this is referring to "normal"

code. Catching them at the top-level still makes sense, e.g. for the unit
testing case mentioned or even just to print a nice error message with
extra information. Using an exception instead of a fatal error also means
that things like "finally" will still run, so your code can still release
locks etc even if an assertion failure occurred.

In production this will never happen. We go round in circles here. I am
aware of you preference on "exceptions everywhere".

Nikita

Hi Pierre,

Assertion is only for development and testing.
We need errors or exceptions during development and testing, but
not in production. Therefore, errors/exception should not be catched
by code in general. Isn't assertion nature?

I don't insist not to enable assertion in production environment.
There might be software that needs extreme reliability and stability.
For these softwares, it makes sense to enable assertions and catch
errors/exceptions to do some cleanups.

This last paragraph makes me wonder why in the world assert in PHP is
still anything valid. If anything it should be removed, to be honest.

Which softwares do not require to be reliable and stable? Most if not
all PHP written software interact with external inputs, be from APIs
point of view or from actual users. Per se, they have to be validated
and errors handling is part of this validation.

I do see some values for asserts in unit tests, but that's pretty much
all I can think about it.

All in all, I stay with my initial comment, this RFC needs more
discussion and some other critical questions must be answered before
this RFC.

We don't put test code checks in production code, do we?
Testing and assertion is to prevent simple bugs, to help finding bugs.
Once development/testing is done, these code will not be needed.

You may think assertion as contracts of code. Once developers ensured
all contracts were kept, contract validations are not needed anymore.
By this proposal, developers can check contracts anywhere in code,
any number of times during development without sacrificing production
code efficiency. This helps to write solid code. Assertion would be
great tool for library/framework developers to prevent users to
abuse/misuse
it also.

Even if we test software with comprehensive manner, software has bugs.
Assertion may help to detected/prevent "unexpected" software behavior.
It's users choice if they enable assertions. Assertions are supposed not
to do any useful checks in production, but it may help.

I agree that users may abuse/misuse assertion, but most tools can be
abused/misused like require()/include(). I agree that users must
validate all input/output (and PHP should help it). These validations must
be done as usual code, not assertion.

I hope I could explain well enough.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Am 28.02.2015 19:32 schrieb "Crypto Compress" <cryptocompress@googlemail.com

:

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?

Put the assert AFTER handling the always-to-be-done validation, of course.
Doesn't make sense otherwise.

Patrick

Hi Crypto,

On Sun, Mar 1, 2015 at 3:32 AM, Crypto Compress <
cryptocompress@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
yohgaki@ohgaki.net