Re: Assertions

From: Date: Fri, 18 Oct 2013 12:26:56 +0000
Subject: Re: Assertions
References: 1 2 3 4 5 6 7 8 9 10 11 12 13  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message 
On 18/10/2013 01:45, Marco Schuster wrote:

On Thu, Oct 17, 2013 at 11:42 PM, Rowan Collins <[email protected]> wrote:

The current implementation allows you to define a callback, and to choose
whether assertions are fatal, which means that unit test frameworks and
fancy-output wrappers can intercept assertions *without affecting other
parts of the code*. The only way to do that with catch blocks would be to
have an exception which didn't descend from Exception.

You could always throw a secondary exception from the catch-block.


It's not so much a question of whether it would be *possible* to write code which handled such situations, as whether it is reasonable to *expect* people to do so: as soon as assert() started throwing exceptions, all code which uses assert() would have to be audited to see what catch blocks the AssertExceptions would fall into, and add extra boilerplate to explicitly re-throw them.

I agree with J David to the extent that whatever behaviour assert() should have, it should be *distinct* from other types of error checking. Having assertions be caught by a catch(Exception) block reduces that distinction while increasing the BC break.

Meanwhile, what is the actual case for catching the assertion in a code block rather than registering a failure callback? So far, it seems to be a case of "callbacks feel a bit old-fashioned" - the uses cases people have mentioned of Unit Tests and pretty debug output are both adequately covered by a simple callback. Is there a situation where you would, for instance, want to catch an AssertionException, do something, and then re-throw it to an outer block?

-- 
Rowan Collins
[IMSoP]

Thread (36 messages)

« previous php.internals (#69674) next »