At 01:41 AM 4/12/2004 -0400, John Coggeshall wrote:
On Mon, 2004-04-12 at 01:27, Adam Maccabee Trachtenberg wrote:
1) None (almost none?) of the internal classes use exceptions. This
makes it difficult (if not impossible) to explain how to use
exceptions because you cannot show a
On 12 Apr 2004 at 12:05, Andi Gutmans wrote:
I agree it's a problem, but as you know, for BC reasons we can't
make all
internal functions throw exceptions. I do suggest however, that
new object
oriented extensions throw exceptions in object context. This isn't a
BC
break and makes sense
On Sun, 11 Apr 2004, David Sklar wrote:
Perfect, thanks. I knew there was a #define lurking around somewhere
that was \r\n, \r, or \n, as appropriate, I just didn't know what it was
called.
I don't think it's a good idea to do this as it causes different output
on different systems. This
On Sun, 11 Apr 2004, John Coggeshall wrote:
As a matter of consistency, I would like to suggest that for those
extensions which have a OO/procedural syntax that the non-fatal errors
generated by those extensions be thrown as Exceptions when called from
an OO syntax. I have already committed
At 12:41 PM 4/12/2004 +0200, Derick Rethans wrote:
On Sun, 11 Apr 2004, John Coggeshall wrote:
As a matter of consistency, I would like to suggest that for those
extensions which have a OO/procedural syntax that the non-fatal errors
generated by those extensions be thrown as Exceptions when
At 12:13 PM 4/12/2004 +0200, Ferdinand Beyer wrote:
On 12 Apr 2004 at 12:05, Andi Gutmans wrote:
I agree it's a problem, but as you know, for BC reasons we can't
make all
internal functions throw exceptions. I do suggest however, that
new object
oriented extensions throw exceptions in object
Derick Rethans wrote:
I think it's a stupid idea (actually OO is a stupid idea but that's
something for another dicussion ;-):
1. In order to silently ignore failed queries you still have to put a
stupid try..except block around it.
If it's used only in object context.
2. KISS: PHP is
At 01:02 PM 4/12/2004 +0200, Andrey Hristov wrote:
Finally, it looks that RC2 won't be released anytime soon and this issue
can be fixed in the meantime.
Actually, I am planning on rolling RC2RC1 in the coming days. I still have
a few pending engine bugs which I want to look at before I do so.
At 01:02 PM 4/12/2004 +0200, Andrey Hristov wrote:
Finally, it looks that RC2 won't be released anytime soon and this issue
can be fixed in the meantime.
BTW, the reason why I think RC2 should be released ASAP is because of the
fix in compatibility_mode and the studlyCaps changes. Both of these
On April 12, 2004 06:45 am, Andi Gutmans wrote:
I don't see a problem with OOP extensions throwing exceptions.
Andi
There is 1 problem with this approach. Currently an uncaught exceptions
results in a fatal error (E_ERROR) meaning that if a particular method throws
an exceptions it MUST be
On Mon, 12 Apr 2004, Ilia Alshanetsky wrote:
There is 1 problem with this approach. Currently an uncaught exceptions
results in a fatal error (E_ERROR) meaning that if a particular method throws
an exceptions it MUST be caught otherwise the script will terminate. Having
to wrap some methods
On Apr 12, 2004, at 10:58 AM, Adam Maccabee Trachtenberg wrote:
On Mon, 12 Apr 2004, Ilia Alshanetsky wrote:
There is 1 problem with this approach. Currently an uncaught
exceptions
results in a fatal error (E_ERROR) meaning that if a particular
method throws
an exceptions it MUST be caught
On Mon, 12 Apr 2004, Adam Maccabee Trachtenberg wrote:
How can anyone rationally design an application when half of their
problems issue errors and the other half throw exceptions? That's a
recipe for disaster.
Exactly the reason why nothing should throw exceptions at all.
Derick
--
PHP
On April 12, 2004 10:58 am, Adam Maccabee Trachtenberg wrote:
Still, you shouldn't be ignoring E_WARNINGs unless you have a good
reason.
There are plenty of situations where E_WARNING can be safely ignored. And even
more situations where E_NOTICE/E_STRICT can be ignored.
Your code cannot
On Mon, 12 Apr 2004, Derick Rethans wrote:
On Mon, 12 Apr 2004, Adam Maccabee Trachtenberg wrote:
How can anyone rationally design an application when half of their
problems issue errors and the other half throw exceptions? That's a
recipe for disaster.
Exactly the reason why nothing
On Mon, 12 Apr 2004, Ilia Alshanetsky wrote:
On April 12, 2004 10:58 am, Adam Maccabee Trachtenberg wrote:
Still, you shouldn't be ignoring E_WARNINGs unless you have a good
reason.
There are plenty of situations where E_WARNING can be safely ignored. And even
more situations where
On Apr 12, 2004, at 3:45 AM, Andi Gutmans wrote:
At 12:41 PM 4/12/2004 +0200, Derick Rethans wrote:
On Sun, 11 Apr 2004, John Coggeshall wrote:
As a matter of consistency, I would like to suggest that for those
extensions which have a OO/procedural syntax that the non-fatal
errors
generated
On April 12, 2004 11:42 am, Adam Maccabee Trachtenberg wrote:
As to E_WARNINGs, what to do? Sometimes they can be safely ignored,
but it takes an experienced programmer to know those cases.
Perhaps, but if you limit the experienced programmer's options and/or make
using more advanced
Adam Maccabee Trachtenberg wrote:
I am willing to concede that SQL parse errors aren't the best example
here, but that doesn't mean extensions should never throw exceptions.
If a user has written code expecting it to work in PHP 4 and PHP 5 with
a registered error handler, it has to be
Your last changes aren't compiling!
john Sun Apr 11 23:14:19 2004 EDT
Modified files:
/php-src/ext/tidy php_tidy.h tidy.c
Log:
- Removed things related to attribute classes / consts which no
longer exist in Tidy
- Changed protos in comment blocks to studlyCaps
- Fixed
Exceptions in languages like Java are used explicitly to catch fatal
errors, not to catch basic errors. Converting warnings to exceptions
would change the meaning of a warning from something which is nice for
development, or logging purposes, but handled by your control flow, into
an
On Apr 12, 2004, at 8:50 AM, George Schlossnagle wrote:
On Apr 12, 2004, at 11:42 AM, Sterling Hughes wrote:
I like OO (*), and I think warnings (non-fatal errors) as exceptions
are a stupid idea. Does that count? ;-)
Exceptions in languages like Java are used explicitly to catch fatal
On Mon, 12 Apr 2004, Greg Beaver wrote:
Adam Maccabee Trachtenberg wrote:
I am willing to concede that SQL parse errors aren't the best example
here, but that doesn't mean extensions should never throw exceptions.
If a user has written code expecting it to work in PHP 4 and PHP 5 with
a
On Mon, 12 Apr 2004 13:02:19 +0200
[EMAIL PROTECTED] (Andrey Hristov) wrote:
Derick Rethans wrote:
I think it's a stupid idea (actually OO is a stupid idea but
that's something for another dicussion ;-):
1. In order to silently ignore failed queries you still have to
put a
On Mon, 2004-04-12 at 13:00, Sterling Hughes wrote:
not end your current control flow branch. Changing E_WARNING's to
errors catchable by try{}catch{} will not only break BC, but will not
make sense for a large number of warnings currently thrown for PHP and
lead to the same
On Apr 12, 2004, at 1:00 PM, Sterling Hughes wrote:
On Apr 12, 2004, at 8:50 AM, George Schlossnagle wrote:
On Apr 12, 2004, at 11:42 AM, Sterling Hughes wrote:
I like OO (*), and I think warnings (non-fatal errors) as exceptions
are a stupid idea. Does that count? ;-)
Exceptions in languages
On Mon, 12 Apr 2004 13:18:51 -0400
[EMAIL PROTECTED] (John Coggeshall) wrote:
snip
Again, we are talking about a very specific situation (PHP 5
extensions written using a dual-syntax model).Things in the PHP 4
branch are not an issue here, there is no expectation that such
things would be
On Apr 12, 2004, at 1:21 PM, Pierre-Alain Joye wrote:
On Mon, 12 Apr 2004 13:18:51 -0400
[EMAIL PROTECTED] (John Coggeshall) wrote:
snip
Again, we are talking about a very specific situation (PHP 5
extensions written using a dual-syntax model).Things in the PHP 4
branch are not an issue here,
Thanks for the line-ending feedback everyone, and Ilia for the code
cleanup. Attached is a diff that implements the (cleaned up) function
and a test file for tests/basic.
If someone with appropriate karma could commit these, that'd be great.
Thanks,
David
Index: ext/standard/file.c
On Apr 12, 2004, at 10:58 AM, Adam Maccabee Trachtenberg wrote:
On Mon, 12 Apr 2004, Ilia Alshanetsky wrote:
There is 1 problem with this approach. Currently an uncaught
exceptions
results in a fatal error (E_ERROR) meaning that if a particular
method throws
an exceptions it MUST be
John has gone ahead and committed a perfect example of where
exceptions just mess things up. In the tidy extension if you try and
set an unknown configuration option it throws an exception. This is
not by any stretch of the imagination an unrecoverable error, but
rather a simple failure.
On Apr 12, 2004, at 2:14 PM, Sterling Hughes wrote:
John has gone ahead and committed a perfect example of where
exceptions just mess things up. In the tidy extension if you try
and set an unknown configuration option it throws an exception.
This is not by any stretch of the imagination an
On Apr 12, 2004, at 11:35 AM, George Schlossnagle wrote:
On Apr 12, 2004, at 2:14 PM, Sterling Hughes wrote:
John has gone ahead and committed a perfect example of where
exceptions just mess things up. In the tidy extension if you try
and set an unknown configuration option it throws an
On Apr 12, 2004, at 3:06 PM, Sterling Hughes wrote:
It is. It's a hardocded portion of their app, and they made a
mistake. They may not care, but it's also possible that they do.
Assuming that they don't care enough to fix it seems equally crazy to
me.
Could be a version mismatch with tidy,
I think the main reason for all of this disagreement, is because PHP
(pre-exception state) is not consistent with its error levels. As mentioned
here, sometimes relatively serious errors are E_WARNINGs and some less
serious errors are E_ERRORs. Now say, we'd map all E_ERRORs (which can be
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)?
Regards
Friedhelm
Index: gd.h
===
RCS
On Mon, 12 Apr 2004, Andi Gutmans wrote:
I think the main reason for all of this disagreement, is because PHP
(pre-exception state) is not consistent with its error levels. As mentioned
here, sometimes relatively serious errors are E_WARNINGs and some less
serious errors are E_ERRORs.
I
Sorry for my interuption, but I read this:
I don't have a strong feeling about this either way, but to play
devils advocate: You requested an option be set. That option could not
be set because it is impossible to set a non-existent option. How do
you know how someone wants to handle that error?
Note that sqlite does have an option to raise exceptions instead of errors.
I haven't tried this myself; Marcus will be able to advise more on how this
works.
--Wez.
try {
$db = new SQLiteDatabase('foo.db');
if ($db-query($sql)) {
// fetch rows
} else {
// handle error
}
On Mon, 12 Apr 2004, Friedhelm Betz wrote:
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)?
Committed, thanks.
Derick
--
PHP Internals - PHP Runtime
Hello,
I don't believe this to be a php-general question, and seems more like a
bug, but I'm soliciting opinions before posting it as such. It _DOES_
seem like an internals problem, but I could be wrong, and if I am,
please explain why.
See the attached code; it has been isolated from PEAR
We can't see your attachment; the list server filters it out. Would you
put it on a web site?
Thanks,
Ken
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
My apologies.
http://sean.caedmon.net/php/crashing_resources.phps
S
Ken Tossell wrote:
We can't see your attachment; the list server filters it out. Would you
put it on a web site?
Thanks,
Ken
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
I was invited by Greg Beaver (cellog), the maintainer of
PEAR package Games_Chess, to help him on the
development.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Claudio Zamana wrote:
I was invited by Greg Beaver (cellog), the maintainer of
PEAR package Games_Chess, to help him on the
development.
Verified - I could use the help :)
Thanks,
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Andi Gutmans wrote:
I think the main reason for all of this disagreement, is because PHP
(pre-exception state) is not consistent with its error levels. As
mentioned here, sometimes relatively serious errors are E_WARNINGs and
some less serious errors are E_ERRORs. Now say, we'd map all E_ERRORs
46 matches
Mail list logo
