Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86863
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain schlueters.de from 217.114.215.10 cause and error)
Message-ID: <1435240516.15676.7.camel@kuechenschabe>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>, Dmitry Stogov <dmitry@zend.com>
Date: Thu, 25 Jun 2015 15:55:16 +0200
In-Reply-To: <CAF+90c9jJVVOwXGrCYo4yWx=LtfqycccNNS3e8AvAO7PhLkiyA@mail.gmail.com>
References: 
	<CAF+90c9jJVVOwXGrCYo4yWx=LtfqycccNNS3e8AvAO7PhLkiyA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Allow exceptions in __toString()
From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

On Thu, 2015-06-25 at 14:52 +0200, Nikita Popov wrote:
> However what it doesn't do, and what I wouldn't consider feasible to do, is
> ensure that every single string conversion in library functions is
> exception safe. Personally I don't think this is a blocking issue, as the
> worst that can happen is usually an additional superfluous warning to be
> thrown, or something similar. If cases like this turn up, we can
> specifically target them.

I don't agree to the assesment that this isn'T a problem. Consider this
extension pseudo-code:


   zval *data = get_data();
   convert_to_string(data);
   store_into_database(Z_STRVAL_P(data));
   return TRUE;

This will store wrong data in the database and report to the user that
there was an error before storing, so the user assumes nothing was
stored.

The only way we can do that imo is by bailing out if an exception is
thrown and introducing yet another set of string conversion functions
for marking exception safe uses. (i.e. convert_to_string_throwing())

johannes