On Wed, 14 Apr 2004, Marcus Boerger wrote:
Hello Marcus --
> > This is actually a pretty nasty side effect of throwing exceptions in
> > ctors because these two lines have *very* different results if they
> > fail:
>
> > $db = new SQLiteDatabase();
> > $db = sqlite_open();
>
> sqlite_open returns
Can someone have a look at cvs.php.net - looks like it's missing
Horde/Auth/autoo.php
Regards
Alan
--
Can you help out?
Need Consulting Services or Know of a Job?
http://www.akbkhome.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Wed, 14 Apr 2004, Marcus Boerger wrote:
>> This is actually a pretty nasty side effect of throwing exceptions in
>> ctors because these two lines have *very* different results if they
>> fail:
>
>> $db = new SQLiteDatabase();
>> $db = sqlite_open();
>
>> The first is fatal; the second isn't.
Hello Adam,
Wednesday, April 14, 2004, 12:58:36 AM, you wrote:
> On Wed, 14 Apr 2004, Marcus Boerger wrote:
>> > If the developer catches it, they handle it. If they don't, PHP
>> > catches it and issues a fatal error.
>>
>> I am not a friend of PHP catching exceptions and converting them to
>>
Hello Adam,
Wednesday, April 14, 2004, 12:58:36 AM, you wrote:
> On Wed, 14 Apr 2004, Marcus Boerger wrote:
>> > If the developer catches it, they handle it. If they don't, PHP
>> > catches it and issues a fatal error.
>>
>> I am not a friend of PHP catching exceptions and converting them to
>>
> Your example is interesting. It shows an error that would be continuable
> from an engine's point of view but not from the script's point of view. It
> shows that there should not be any possibility to recover from exceptions
> at the exact spot where the exception was thrown - anyway somthing th
On Wed, 14 Apr 2004, Marcus Boerger wrote:
> > If the developer catches it, they handle it. If they don't, PHP
> > catches it and issues a fatal error.
>
> I am not a friend of PHP catching exceptions and converting them to
> E_ERRORs. Just have an uncaught exception message as we have now.
> And
Hello Adam,
Tuesday, April 13, 2004, 11:15:11 PM, you wrote:
> On Tue, 13 Apr 2004, Marcus Boerger wrote:
>> > In PHP 4, E_ERROR is fatal. In PHP 5, E_ERROR is (currently) also
>> > fatal. This always happens regardless of any exception handling.
>>
>> > With exceptions, we have the ability to m
Derick,
Can you commit a patch so that I can roll it tomorrow?
Thanks,
Andi
At 08:34 PM 4/13/2004 +0200, Derick Rethans wrote:
Hello Guys/Gals,
On Tue, 13 Apr 2004, Andi Gutmans wrote:
> I want to roll RC2RC1. There are three major changes I think we should get
> out of the door ASAP:
I've on
On Apr 13, 2004, at 5:50 PM, David Sklar wrote:
George Schlossnagle wrote:
This doesn't print "Brray" or maybe "Arraz"? :)
Not even in Perl.
George
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
George Schlossnagle wrote:
This doesn't print "Brray" or maybe "Arraz"? :)
David
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Apr 13, 2004, at 5:18 PM, Adam Maccabee Trachtenberg wrote:
On Tue, 13 Apr 2004, George Schlossnagle wrote:
On Apr 13, 2004, at 4:52 PM, Adam Maccabee Trachtenberg wrote:
I guess I'm confused about why some E_ERRORs are now able to be
handled in userland, but only by using exceptions.
It's imp
On Tue, 13 Apr 2004, George Schlossnagle wrote:
> On Apr 13, 2004, at 4:52 PM, Adam Maccabee Trachtenberg wrote:
> >
> > I guess I'm confused about why some E_ERRORs are now able to be
> > handled in userland, but only by using exceptions.
>
> It's important to note that this is now technically fe
On Tue, 13 Apr 2004, Marcus Boerger wrote:
> > In PHP 4, E_ERROR is fatal. In PHP 5, E_ERROR is (currently) also
> > fatal. This always happens regardless of any exception handling.
>
> > With exceptions, we have the ability to modify E_ERRORs to be
> > non-fatal.
>
> Not at the moment.
Ah. Okay.
On Apr 13, 2004, at 4:52 PM, Adam Maccabee Trachtenberg wrote:
I guess I'm confused about why some E_ERRORs are now able to be
handled in userland, but only by using exceptions.
It's important to note that this is now technically feasible but not
(yet) part of PHP. (You can actually do it as an e
Hello Adam,
Tuesday, April 13, 2004, 10:52:01 PM, you wrote:
> On Tue, 13 Apr 2004, George Schlossnagle wrote:
>> > Is there a reason not to move non-continuable E_ERRORs to E_WARNINGs?
>> > This prevents us from adding another severity level and also allows us
>> > to make all E_ERRORs fatal in
On Tue, 13 Apr 2004, George Schlossnagle wrote:
> > Is there a reason not to move non-continuable E_ERRORs to E_WARNINGs?
> > This prevents us from adding another severity level and also allows us
> > to make all E_ERRORs fatal in the process.
>
> This is a huge bc break. Raising the severity on
Hello Christian,
Tuesday, April 13, 2004, 10:20:50 PM, you wrote:
> Marcus Boerger wrote:
>> 2) Use exceptions when a ctor needs to advertise its failure and in other
>>places where exceptions are really usefull.
> ... and make the exception in the ctor an option, not the default IMHO.
>> T
Hello Derick,
Tuesday, April 13, 2004, 10:24:24 PM, you wrote:
> On Tue, 13 Apr 2004, Adam Maccabee Trachtenberg wrote:
>> On Tue, 13 Apr 2004, Marcus Boerger wrote:
>>
>> > This brings us back to an old problem the severity levels are inconsistent.
>> > And further more we decided some time bac
On Apr 13, 2004, at 4:16 PM, Adam Maccabee Trachtenberg wrote:
On Tue, 13 Apr 2004, Marcus Boerger wrote:
Hello Marcus --
This brings us back to an old problem the severity levels are
inconsistent.
And further more we decided some time back that E_ERRORs shouldn't be
converted to exceptions bec
On Tue, 13 Apr 2004, Adam Maccabee Trachtenberg wrote:
> On Tue, 13 Apr 2004, Marcus Boerger wrote:
>
> > This brings us back to an old problem the severity levels are inconsistent.
> > And further more we decided some time back that E_ERRORs shouldn't be
> > converted to exceptions because of a f
Marcus Boerger wrote:
2) Use exceptions when a ctor needs to advertise its failure and in other
places where exceptions are really usefull.
... and make the exception in the ctor an option, not the default IMHO.
Too much exception is a bad thing anyway.
Yes, it has to be a really severe error,
On Tue, 13 Apr 2004, Marcus Boerger wrote:
Hello Marcus --
> This brings us back to an old problem the severity levels are inconsistent.
> And further more we decided some time back that E_ERRORs shouldn't be
> converted to exceptions because of a few E_ERRORs that might not be
> continuable. Fro
Hello Derick,
Tuesday, April 13, 2004, 9:28:38 AM, you wrote:
> On Tue, 13 Apr 2004, Greg Beaver wrote:
>> I don't think that exceptions suck, but I agree that they are limited in
>> their usefulness, just as you describe in the first paragraph. The
>> majority of error conditions aren't severe
Rosen Vilijanov Ivanov wrote:
I want to translate the documentation to my native language (Bulgarian)
Well, you have to talk with Kouber Saparev (kouber at php _dot_ net) who got DOC CVS karma
but according to Bonsai (bonsai.php.net) has never used it. Also there is no phpdoc-bg
module in CVS. W
Hello Wez,
SQLite only throws exceptions from constructors. This is necessary to get
the "constructor failed" information. It works using the support functions
from main/main.c/main/php.h:
typedef enum {
EH_NORMAL = 0,
EH_SUPPRESS,
EH_THROW
} error_handling_t;
PHPAPI void
On April 13, 2004 02:34 pm, Derick Rethans wrote:
> I've one other thing to propose, and that is enabling iconv by default.
+1 given that we enable xml extensions that via libxml2 use iconv, we might as
well enable the iconv extension as well.
Ilia
--
PHP Internals - PHP Runtime Development Ma
+1 (and it's already on by default in the win32 build).
--Wez.
> I've one other thing to propose, and that is enabling iconv by default.
> Now you might ask why iconv and not mbstring? Well, that's easy as the
> author of mbstring (Moriyoshi) thinks of moving it to PECL, out of the
> core. Why I
The change wasn't actually to make Tidy throw exceptions, but rather to
throw errors instead of exceptions (until recently, Tidy would throw
exceptions in either OO or procedural contexts).
Although I could change Tidy to not throw exceptions, I am inclinded to
leave it as is (maybe change the er
Hello Guys/Gals,
On Tue, 13 Apr 2004, Andi Gutmans wrote:
> I want to roll RC2RC1. There are three major changes I think we should get
> out of the door ASAP:
I've one other thing to propose, and that is enabling iconv by default.
Now you might ask why iconv and not mbstring? Well, that's easy a
Should be fixed ready for the next snap.
--Wez.
- Original Message -
From: "Nuno Lopes" <[EMAIL PROTECTED]>
To: "PHPdev" <[EMAIL PROTECTED]>
Sent: Tuesday, April 13, 2004 6:21 PM
Subject: [PHP-DEV] snaps
> snaps aren't compiling: http://snaps.php.net/win32/snapshot.log
>
> --
> PHP I
snaps aren't compiling: http://snaps.php.net/win32/snapshot.log
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Tue, 13 Apr 2004, Christian Schneider wrote:
> > This also means that extensions usually should not throw
> > exceptions at all, as they are not supposed to throw E_ERRORs that abort
> > scripts right away.
>
> Just curious: Is there such a policy right now? If so then this policy
> should be e
Derick Rethans wrote:
Then they are abusing exceptions big time. Throwing exceptions for
E_ERROR conditions *might* be a good idea, but for anything lower than
that: no way.
I agree wholeheartedly. Having worked with (Java) exceptions I realized
that it is a _very_ hard instrument to use properly
Guys,
I want to roll RC2RC1. There are three major changes I think we should get
out of the door ASAP:
- zend.ze1_compatibility_mode fix.
- MT-safe crash bug.
- studlyCaps changes.
The only important issue I see is John's change of tiny to throw
exceptions. As there's no way we will finalize ou
Andi Gutmans wrote:
Yeah, I think the best fix would be to change the fontFetch() function
to look for the fonts in getenv("windir")+"/fonts" instead of hardcoding
the dir names. I'm sure there are some weird people who call their
windows installation neither by winnt nor windows.
Or more common
I want to translate the documentation to my native language (Bulgarian)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
GB>>I suspect this is because it is possible to differentiate between
GB>>error type, and even severity, just through the class of the
GB>>exception. Perhaps some kind of non-fatal exception equivalent could
GB>>be worked out for 5.1/5.2?
That would be contradiction in terms. Exception means - "s
On Tue, 13 Apr 2004, Greg Beaver wrote:
> I don't think that exceptions suck, but I agree that they are limited in
> their usefulness, just as you describe in the first paragraph. The
> majority of error conditions aren't severe enough to need them.
> Unfortunately, many developers I have talked
39 matches
Mail list logo
