Re: RFC: Expectations

From: Date: Mon, 21 Oct 2013 10:13:57 +0000
Subject: Re: RFC: Expectations
References: 1 2  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message 
On 10/21/2013 10:57 AM, Derick Rethans wrote:

On Fri, 18 Oct 2013, Joe Watkins wrote:


Evening Chaps,

	Following on from discussion regarding assertion API in PHP, the
following RFC is now up for discussion:

	https://wiki.php.net/rfc/expectations

	Please do point out any missing sections or information, so that it
can be clarified as quickly as possible.
	
	I hope this conveys the idea a bit clearer to everyone ?


This is again an RFC that does not even attempt to argue for its
usefulness. "This functionality was meant to replace the assert() API
that currently exists in PHP, because of problems replacing it in a
compatible manner". This doesn't say what is wrong with assert() or
whether we *need* expect.

Besides that, why support execptions here. asserts are for testing
things in development in order not to cock things up. Using exceptions
for this makes very little sense. All of your examples even promote to
handle exceptions and continue with excecution. If you want that, just
use normal if()s with exceptions. I don't see the point of yet another
syntax extension to do things you can already do just fine.

cheers,
Derick



The performance of the current assert API is unacceptable during development due to the fact it is a function that utilizes strings and eval, and cannot be disabled completely during production because it's a function not a language construct. This makes it quite devastating to deploy, it seems obvious we should seek to replace it.

We should support exceptions here because it gives a reasonable way to manage the error without impacting anything else, without requiring module globals, ini settings, or supporting functions in userland.
By manage I do not necessarily mean continue executing, I mean that it is never really acceptable or useful for a web application to quit, writing a single exception to standard error. It is useful to be able to manage the error to collect more information about the state of the application, gain access to a stack trace, and do something actually useful.

Not all of the examples promote continuing execution, at all, I think only one actually does. I mention once that continuing execution is an option, just like it is when you catch any other exception.

Cheers
Joe

Thread (51 messages)

« previous php.internals (#69726) next »