On 11/25/2011 04:21 AM, Sebastian Krebs wrote:
2011/11/25 Ferenc Kovacs
The problem with fatal, that you have no way (by the standard means, but
you can somehow manage it through the usage of output buffers or
register_shutdown_function, but thats ugly, and can change in the future)
to intercep
Trying implement empty getter/setter syntax such as:
public $Hours {
get;
set;
}
Is there any way to "inject" code into the compile process?
I'm trying via (just some proof of concept code, ignore the buffer overrun
potential)
char injected
Yesterday we were talking about enabling more extensions and adding pecl
> into the mix:
> http://www.mail-archive.com/internals@lists.php.net/msg54220.html
> I think it would be a good idea to try to fix the currently failing tests.
> http://ci.qa.php.net/job/php-src-5.3-matrix-tests/35/testReport
Hi,
First off, it would've been better to contact one of the project members
rather than the internals list :)
To answer your question though, I'm assuming that you're accessing a secure
http url, which requires openssl iirc.
Please address any replies to me directly and/or ja...@php.net
Thanks
Hi,
Paul Dragoonis directed me to you with a question about the internals of
PECL OAuth.
Upon calling OAuth::getRequestToken() the following Exception is thrown if I
have not explicitely set the request engine using OAuth::setRequestEngine():
Fatal error: Uncaught exception 'OAuthException'
Am 25.11.2011 13:34, schrieb Ferenc Kovacs:
On Fri, Nov 25, 2011 at 1:28 PM, Christian Kaps
wrote:
Am 25.11.2011 13:13, schrieb Ferenc Kovacs:
On Fri, Nov 25, 2011 at 12:56 PM, Christian Kaps
**wrote:
I surround my application with a try/catch block to catch uncaught
exceptions. An autoloa
On Fri, Nov 25, 2011 at 1:28 PM, Christian Kaps
wrote:
> Am 25.11.2011 13:13, schrieb Ferenc Kovacs:
>
>> On Fri, Nov 25, 2011 at 12:56 PM, Christian Kaps
>> **wrote:
>>
>> I surround my application with a try/catch block to catch uncaught
>>> exceptions. An autoloader exception could be one of t
Am 25.11.2011 13:13, schrieb Ferenc Kovacs:
On Fri, Nov 25, 2011 at 12:56 PM, Christian Kaps
wrote:
I surround my application with a try/catch block to catch uncaught
exceptions. An autoloader exception could be one of them.
But I use also similar calls to reformat error messages.
try {
$cl
On Fri, Nov 25, 2011 at 12:56 PM, Christian Kaps
wrote:
> I surround my application with a try/catch block to catch uncaught
> exceptions. An autoloader exception could be one of them.
>
> But I use also similar calls to reformat error messages.
>
> try {
> $class = new ReflectionClass($**annota
Can we stay on topic please. At this time I count a vast number of
mails, but never has talked about the RFC.
Fact is that these three cases, how a autoloader terminates, exists in
PHP. If all these cases are useful is an other topic. Can we all agree
on this?
Am 25.11.2011 11:21, schrieb S
Also missing JSON_BIGINT_AS_STRING .
With regards, Alexander Moskaliov
ir...@irker.net
I surround my application with a try/catch block to catch uncaught
exceptions. An autoloader exception could be one of them.
But I use also similar calls to reformat error messages.
try {
$class = new ReflectionClass($annotationName);
} catch (ClassNotFoundException $e) {
$message = "The
On Fri, Nov 25, 2011 at 11:21 AM, Sebastian Krebs
wrote:
> 2011/11/25 Ferenc Kovacs
>
> > The problem with fatal, that you have no way (by the standard means, but
> > you can somehow manage it through the usage of output buffers or
> > register_shutdown_function, but thats ugly, and can change in
2011/11/25 Ferenc Kovacs
> The problem with fatal, that you have no way (by the standard means, but
> you can somehow manage it through the usage of output buffers or
> register_shutdown_function, but thats ugly, and can change in the future)
> to intercept and gracefully terminate your applicati
The problem with fatal, that you have no way (by the standard means, but
you can somehow manage it through the usage of output buffers or
register_shutdown_function, but thats ugly, and can change in the future)
to intercept and gracefully terminate your application, which is an often
needed featur
On Fri, Nov 25, 2011 at 10:18 AM, Ford, Mike wrote:
> I echo that sentiment. On fuller review, I find a very high FUD
> factor in effect here, and on actually checking my codebase I find
> only 1 place where an additional is_array() *might* be needed (in
> several tens of kLOC!).
That's exactly
On Fri, Nov 25, 2011 at 4:07 AM, Daniel Convissor <
dani...@analysisandsolutions.com> wrote:
> Hi Anthony:
>
> > isset($foo['bar'][1]['baz']) && is_array($foo['bar'][1])
> >
> > You don't need to check each level. Only the one above the key you're
> > looking at.
>
> Excellent thinking. One hitc
If your autoloader throws an exception, you need to try/catch entire
application. It doesn't sounds useful. On my view, if you want to be
mailed about an autoloader fail, this have to be coded inside of your
own single autoloader.
On Fri, Nov 25, 2011 at 7:46 AM, Christian Kaps
wrote:
> Am 25.11.
On Fri, Nov 25, 2011 at 3:52 AM, Daniel Convissor <
dani...@analysisandsolutions.com> wrote:
> Hi Rasmus:
>
> > Yes, no change in any of that. In your usage, the case that behaves
> > differently in 5.4 was actually a fatal error in 5.3, so chances are
> > pretty good you don't have too many of th
Am 25.11.2011 10:34, schrieb Rafael Kassner:
I think an autoloader can't be raise any kind of error. If the class
will be loaded by another autoloader on the stack and the first
throws
an Exception, this will be a wrong behavior.
Indeed, if autoloader can't include the class, PHP throws a fatal
Hi,
comments inline.
Am 25.11.2011 09:56, schrieb Sebastian Krebs:
Hi,
Just to throw my 2 cent in: Im with Micheal. An application, that
tries to
access a class, that doesn't exists, is broken and a FATAL is valid.
This
application doesn't need try-catch, but a bugfix (and if it is
already
I think an autoloader can't be raise any kind of error. If the class
will be loaded by another autoloader on the stack and the first throws
an Exception, this will be a wrong behavior.
Indeed, if autoloader can't include the class, PHP throws a fatal
error, and you can avoid it using class_exists f
> -Original Message-
> From: Larry Garfield [mailto:la...@garfieldtech.com]
> Sent: 24 November 2011 22:04
[... BIG SNIP ...]
> If that doesn't change, then I rescind my previous panic attack.
>
> --Larry Garfield
I echo that sentiment. On fuller review, I find a very high FUD
factor i
Am 25.11.2011 09:55, schrieb Sebastian Bergmann:
Am 25.11.2011 09:06, schrieb Christian Kaps:
Or am i wrong here?
Yes you are. The idea is that you can have multiple autoload
callbacks
which are invoked in sequence. The first one that is able to load
the
requested class will end that sequ
Hi,
Just to throw my 2 cent in: Im with Micheal. An application, that tries to
access a class, that doesn't exists, is broken and a FATAL is valid. This
application doesn't need try-catch, but a bugfix (and if it is already
released: A better testing management).
On the other side an application,
Am 25.11.2011 09:06, schrieb Christian Kaps:
> Or am i wrong here?
Yes you are. The idea is that you can have multiple autoload callbacks
which are invoked in sequence. The first one that is able to load the
requested class will end that sequence. If you throw exceptions in one
autoloader that
Am 25.11.2011 08:24, schrieb Michael Wallner:
On Thu, 24 Nov 2011 23:28:35 +0100, Christian Kaps wrote:
https://wiki.php.net/rfc/autoloader_error_handling
Throwing an exception or fatal error in an autoloader
absolutely does not make any sense in my eyes.
Projects doing this should step bac
27 matches
Mail list logo
