On Fri, July 24, 2009 9:35 am, Alexey Zakhlestin wrote:
> On Fri, Jul 24, 2009 at 6:29 PM, Hannes
> Magnusson wrote:
>> On Fri, Jul 24, 2009 at 15:43, Ben Scholzen
>> 'DASPRiD' wrote:
>>> To you both, this is especially, for library code like Zend
>>> Framework.
>>> The library cannot expect the us
On Fri, July 24, 2009 11:00 am, Matt Wilson wrote:
> I agree, however there are certain aspects of PHP's errors that leave
> a lot to be desired. For instance, a failed fopen or a failed socket
> will often result in an uncatchable warning from php. Sure, you can
> add a @ to the line but that's sl
On Fri, July 24, 2009 8:43 am, Ben Scholzen 'DASPRiD' wrote:
> To you both, this is especially, for library code like Zend Framework.
> The library cannot expect the user to have the error handle set, so it
> would have to replace the error handler before every line which it
> wants
> to try {} and
Hello,
u...@domain.invalid wrote:
> I published a (work in progress) RFC today about replacing certain
> errors with exceptions. I know that there already was something similiar
> on the php6dev blog, but this is not completly the same, so awating your
> comments:
>
> http://wiki.php.net/rfc/erro
Matt Wilson wrote:
> I agree, however there are certain aspects of PHP's errors that leave a
> lot to be desired. For instance, a failed fopen or a failed socket will
> often result in an uncatchable warning from php. Sure, you can add a @
> to the line but that's slow and doesn't tell you anything
Sorry for top post, on my android. I disagree that php has perl phobia, but
I agree that a alternative to errors needs to be made. Your example is nice
but might have some tricky implementation details if php continued to throw
errors when it didn't detect $!. I.E. fopen(...) or throw new
CustomExc
I agree, however there are certain aspects of PHP's errors that leave
a lot to be desired. For instance, a failed fopen or a failed socket
will often result in an uncatchable warning from php. Sure, you can
add a @ to the line but that's slow and doesn't tell you anything
about what happene
On 7/24/09 6:43 AM, Ben Scholzen 'DASPRiD' wrote:
To you both, this is especially, for library code like Zend Framework.
This tends to invalidate your entire argument IMO. Changing the core
language because something is hard in an external framework that only a
small percentage of actual PHP
On Fri, Jul 24, 2009 at 16:35, Alexey Zakhlestin wrote:
> On Fri, Jul 24, 2009 at 6:29 PM, Hannes
> Magnusson wrote:
>> On Fri, Jul 24, 2009 at 15:43, Ben Scholzen 'DASPRiD'
>> wrote:
>>> To you both, this is especially, for library code like Zend Framework.
>>> The library cannot expect the user
On Fri, Jul 24, 2009 at 6:29 PM, Hannes
Magnusson wrote:
> On Fri, Jul 24, 2009 at 15:43, Ben Scholzen 'DASPRiD' wrote:
>> To you both, this is especially, for library code like Zend Framework.
>> The library cannot expect the user to have the error handle set, so it
>> would have to replace the er
On Fri, Jul 24, 2009 at 15:43, Ben Scholzen 'DASPRiD' wrote:
> To you both, this is especially, for library code like Zend Framework.
> The library cannot expect the user to have the error handle set, so it
> would have to replace the error handler before every line which it wants
> to try {} and r
On 24.07.2009, at 16:06, Ben Scholzen 'DASPRiD' wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kalle Sommer Nielsen wrote:
Then ZF should provide an error handler that can be called inside the
user's error handler or simply choose to not use error handlers if
the
user have a custom e
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kalle Sommer Nielsen wrote:
> Then ZF should provide an error handler that can be called inside the
> user's error handler or simply choose to not use error handlers if the
> user have a custom error handler. I can't really see why the whole
> language
Please don't top post
2009/7/24 Ben Scholzen 'DASPRiD' :
> To you both, this is especially, for library code like Zend Framework.
> The library cannot expect the user to have the error handle set, so it
> would have to replace the error handler before every line which it wants
> to try {} and rese
To you both, this is especially, for library code like Zend Framework.
The library cannot expect the user to have the error handle set, so it
would have to replace the error handler before every line which it wants
to try {} and reset it after the catch. This is not really a clean
solution, at it c
2009/7/24 :
> I published a (work in progress) RFC today about replacing certain
> errors with exceptions. I know that there already was something similiar
> on the php6dev blog, but this is not completly the same, so awating your
> comments:
>
> http://wiki.php.net/rfc/errors_as_exceptions
>
I'm
On Fri, Jul 24, 2009 at 3:23 PM, wrote:
> I published a (work in progress) RFC today about replacing certain
> errors with exceptions. I know that there already was something similiar
> on the php6dev blog, but this is not completly the same, so awating your
> comments:
>
> http://wiki.php.net/rfc
I published a (work in progress) RFC today about replacing certain
errors with exceptions. I know that there already was something similiar
on the php6dev blog, but this is not completly the same, so awating your
comments:
http://wiki.php.net/rfc/errors_as_exceptions
--
PHP Internals - PHP Runti
18 matches
Mail list logo
