At 10:28 PM 4/12/2004 +0200, Friedhelm Betz wrote:
Hi,
attached patches add c:\windows\fonts to DEFAULT_FONTPATH.
c:\windows\fonts is the standard for Windows 98 and windows XP.
Maybe a more sophisticated solution would use getenv(windir)?
Yeah, I think the best fix would be to change the
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 to
GBI suspect this is because it is possible to differentiate between
GBerror type, and even severity, just through the class of the
GBexception. Perhaps some kind of non-fatal exception equivalent could
GBbe worked out for 5.1/5.2?
That would be contradiction in terms. Exception means -
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
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 commonly,
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
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
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 extended
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
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 Internals -
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 as
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
+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
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
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 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. From
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, 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 few
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
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 back that
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.
Too much
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 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 the
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
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. I guess I
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 feasible
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
George Schlossnagle wrote:
?php
$a = array() + 1;
?
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:50 PM, David Sklar wrote:
George Schlossnagle wrote:
?php
$a = array() + 1;
?
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
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 one
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 modify
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 no way
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 that
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
E_ERRORs.
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
E_ERRORs.
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.
So to use
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:
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 a resource
38 matches
Mail list logo
