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 meanin
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 se
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 me
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 committe
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 suppose
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.
A
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 c
On Mon, 12 Apr 2004, Andi Gutmans wrote:
> I think that functional context should continue to work as usual, but
> there's a big advantage to be able to catch problems with try/catch and not
> have to if() each internal function call separately (which you probably
> don't do :)
> I don't see a pro
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 method
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 othe
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 c
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 n
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
> generate
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
errors, not to catch basic errors.
If 'languages like Java' mean
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 capabili
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 completely
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
> -
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 unrecover
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
errors,
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 w
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
>
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 inconsisten
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:
> 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 chan
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:
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
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 excep
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. Y
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 exce
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
recov
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 fi
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 a
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 (co
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: http://www.php.net/unsub
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
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 fontF
49 matches
Mail list logo
