Am 21.02.2015 um 04:10 schrieb Yasuo Ohgaki:
Hi Crypto,
On Fri, Feb 20, 2015 at 11:02 PM, Crypto Compress
<cryptocompr...@googlemail.com <mailto:cryptocompr...@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.
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.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net <mailto:yohg...@ohgaki.net>
Hi Yasuo,
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.
cryptocompress
