Re: RFC: Expectations

From: Date: Tue, 22 Oct 2013 18:07:09 +0000
Subject: Re: RFC: Expectations
References: 1 2 3 4 5 6 7  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message 
On 10/22/2013 06:56 PM, Adam Harvey wrote:

On 22 October 2013 10:32, Joe Watkins <[email protected]> wrote:

On 10/22/2013 06:20 PM, Adam Harvey wrote:

I agree that something to replace the eval-based assert() would be
good. What if the new syntax simply respected assert_options(), and
assert_options() was extended to support an explicit ASSERT_EXCEPTION
control option (that presumably took an exception class name as its
option value)? That seems like it would provide the exception based
possibilities that some posters want while maintaining the same
assertion behaviour that users are already used to by default.


I'm a bit perplexed at the need to retain any compatibility with what is a
poor implementation ?


To be fair, I think part of the disconnect here is that I don't feel
like the current implementation is particularly poor besides the
eval-based API. I don't really want an assertion failure to throw an
exception — if I did, I'd use an assert callback or ErrorException to
do that. I want it logged so I can look at it later, and that's easily
configured with the current assertion setup.

I guess I'm wondering if there's a middle ground here, rather than
throwing the assertion baby out with the bathwater in favour of an
entirely new thing that could simply be syntax sugar sprinkled over an
existing, working implementation.

Adam



You can catch exceptions, and log them.
You can do that without impacting everything around you, you can do that, or whatever else you like.

There is one camp saying we want to catch exceptions and have access to stack traces and the current scope, others who say that there is no need and the application can quit, now some who say they want to log ...

There is no need for any of this to go on at the level of the implementation, it is a restriction on the implementation to do so.

I can't stress enough how important it is that, used correctly, the impact of assertion during development is completely removed at runtime in production, completely removed, not by any voodoo, but by core software o+. That is of paramount importance for the ideal implementation, and we have that right now, there is no convincing reason to let it go.

Cheers
Joe

Thread (51 messages)

« previous php.internals (#69774) next »