I'm not sure how much Java code you have seen/written but this tends to
lead to a million of empty try/catch statements which only lead to a false
sense of security because in practice, you are barely handling any exceptions.
At 11:05 AM 4/16/2004 +1200, Jevon Wright wrote:
> Guys, I'm am not fo
Hello Jevon,
Friday, April 16, 2004, 1:05:11 AM, you wrote:
>> Guys, I'm am not for forcing people to use exceptions. I agree that we
>> should make PHP another Java exceptions from hell (especially with their
>> exception declarations in function prototypes which is horrible). I'm just
>> saying
> Guys, I'm am not for forcing people to use exceptions. I agree that we
> should make PHP another Java exceptions from hell (especially with their
> exception declarations in function prototypes which is horrible). I'm just
> saying, that some extensions might benefit from exceptions and the
> ext
On Apr 15, 2004, at 5:21 PM, Marcus Boerger wrote:
Hello Christian,
Thursday, April 15, 2004, 1:06:20 PM, you wrote:
[EMAIL PROTECTED] wrote:
"modern dynamic" languages in that context, as for instance in Python
there is no error handling but by using exceptions).
Sorry but that's simply wrong.
Hello Christian,
Thursday, April 15, 2004, 1:06:20 PM, you wrote:
> [EMAIL PROTECTED] wrote:
>> "modern dynamic" languages in that context, as for instance in Python
>> there is no error handling but by using exceptions).
> Sorry but that's simply wrong. Python methods can return false or null
Hello Derick,
Thursday, April 15, 2004, 11:02:14 PM, you wrote:
> On Thu, 15 Apr 2004, Marcus Boerger wrote:
>> I don't. If you don't like the oo interface of SQLite then go with the
>> procedural API. For the way i implemented SQLite's oo API exceptions are the
>> way to go - a gingle exception
On Thu, 15 Apr 2004, Marcus Boerger wrote:
> I don't. If you don't like the oo interface of SQLite then go with the
> procedural API. For the way i implemented SQLite's oo API exceptions are the
> way to go - a gingle exception in the ctor.
There is nothing wrong with that at all, it's just the o
Hello Christian,
Thursday, April 15, 2004, 1:15:03 PM, you wrote:
> Andi Gutmans wrote:
>> I don't think allowing the return of anything except for the object
>> itself is *fixing* PHP.
> No, being able to fail and return would not be fixing it. It would be
> extending it to allow people to av
Hello Derick,
Thursday, April 15, 2004, 9:59:23 AM, you wrote:
> On Thu, 15 Apr 2004, Andi Gutmans wrote:
>> I don't like these ideas. I think it should stay the way it is and not only
>> because we're at RC2.
>> If Thies doesn't want to deal with this, then he can write constructors
>> without
Hello Jani,
Thursday, April 15, 2004, 10:49:17 PM, you wrote:
> On Thu, 15 Apr 2004, Andi Gutmans wrote:
>>Guys, I'm am not for forcing people to use exceptions.
> Marcus is.. :)
I don't. If you don't like the oo interface of SQLite then go with the
procedural API. For the way i implemente
On Thu, 15 Apr 2004, Andi Gutmans wrote:
>Guys, I'm am not for forcing people to use exceptions.
Marcus is.. :)
> I agree that we should make PHP another Java exceptions from hell
> (especially with their exception declarations in function prototypes which
> is horrible). I'm just
I
On Thu, 15 Apr 2004, George Schlossnagle wrote:
>
>On Apr 15, 2004, at 9:49 AM, Jani Taskinen wrote:
>
>> On Thu, 15 Apr 2004, George Schlossnagle wrote:
>>
>>> On Apr 15, 2004, at 8:28 AM, Christian Schneider wrote:
No, I dislike them because they create more problems than they solve.
>>>
>>
At 01:15 PM 4/15/2004 +0200, Christian Schneider wrote:
Andi Gutmans wrote:
I don't think allowing the return of anything except for the object
itself is *fixing* PHP.
No, being able to fail and return would not be fixing it. It would be
extending it to allow people to avoid exceptions for this s
Brad Fisher wrote:
Lukas Smith wrote:
Our original idea was to handle this with an if statement like so:
if (version_compare(phpversion(), "5.0.0") == -1) {
// assign factoried method to this for PHP 4
// $this =& ::factory();
// $this =& ::singleton();
eval('$this =& ::singleton();');
S
Lukas Smith wrote:
> > Our original idea was to handle this with an if statement like so:
> > if (version_compare(phpversion(), "5.0.0") == -1) {
> > // assign factoried method to this for PHP 4
> > // $this =& ::factory();
// $this =& ::singleton();
eval('$this =& ::singleton();');
> >
On Apr 15, 2004, at 9:49 AM, Jani Taskinen wrote:
On Thu, 15 Apr 2004, George Schlossnagle wrote:
On Apr 15, 2004, at 8:28 AM, Christian Schneider wrote:
No, I dislike them because they create more problems than they solve.
Then don't use them. You're a bit late to the party to debate their
On Thu, 15 Apr 2004, George Schlossnagle wrote:
>On Apr 15, 2004, at 8:28 AM, Christian Schneider wrote:
>> No, I dislike them because they create more problems than they solve.
>
>Then don't use them. You're a bit late to the party to debate their
But if some extension (e.g. sqlite) forces
George Schlossnagle wrote:
Then don't use them. You're a bit late to the party to debate their
existence in the language.
I was late pointing out that copy-on-assignment is a mistake in PHP4, I
was late pointing out that there is no migration path for __clone(), I
was late with PPP and exceptio
On Apr 15, 2004, at 8:28 AM, Christian Schneider wrote:
No, I dislike them because they create more problems than they solve.
Then don't use them. You're a bit late to the party to debate their
existence in the language.
George
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscr
Lukas Smith wrote:
Our original idea was to handle this with an if statement like so:
if (version_compare(phpversion(), "5.0.0") == -1) {
// assign factoried method to this for PHP 4
// $this =& ::factory();
$this =& ::singleton();
} else {
// error handling for PHP5
// user ha
[EMAIL PROTECTED] wrote:
Actually those are a 'modern/dynamic' aspect of Java (being pseudo-closures).
And a very bad one indeed. Not everything modern is good.
dicuss on objective, rational arguments than on pure personal preference.
I gave more than enough rational arguments. If you don't accept
Just to add some more thoughts to the ongoing discussion from a slightly
different POV.
The PEAR devs are trying to slowly prepare their packages for PHP5 and
so we also needed to address assignedments to $this in constructors in
the few packages that do so.
http://pear.php.net/bugs/bug.php?id
> [EMAIL PROTECTED] wrote:
>> First of all, PHP's object model is most similar to the Java one, so
>> Markus' comparisons make most sense in my eyes.
>
> The object model might be similar to Java (it's a very simple one which
> I like) but the language is not and *should not be* IMHO. Java got much
Andi Gutmans wrote:
I don't think allowing the return of anything except for the object
itself is *fixing* PHP.
No, being able to fail and return would not be fixing it. It would be
extending it to allow people to avoid exceptions for this simple case.
For example, in the SOAP extension it is ve
[EMAIL PROTECTED] wrote:
First of all, PHP's object model is most similar to the Java one, so
Markus' comparisons make most sense in my eyes.
The object model might be similar to Java (it's a very simple one which
I like) but the language is not and *should not be* IMHO. Java got much
too bloated
On Thu, 15 Apr 2004, Andi Gutmans wrote:
> I don't like these ideas. I think it should stay the way it is and not only
> because we're at RC2.
> If Thies doesn't want to deal with this, then he can write constructors
> without logic. It's not that hard for the one in many classes where this
> migh
I don't like these ideas. I think it should stay the way it is and not only
because we're at RC2.
If Thies doesn't want to deal with this, then he can write constructors
without logic. It's not that hard for the one in many classes where this
might be needed.
Andi
At 08:20 AM 4/15/2004 +0200,
Hello Sterling,
Thursday, April 15, 2004, 7:55:17 AM, you wrote:
> On Apr 14, 2004, at 10:36 PM, Thies C.Arntzen wrote:
>> if ctors are the only place that *cannot* life without exceptions it
>> would be well worth *fixing* (yes, i said fix), as adding
>> "understanding exceptions" to the list
Hello Thies,
Return NULL wouldn't work because a ctor always returns NULL by
default so we nee a trick. Would reallowing $this = NULL in ctors
only and direct return and disallowing any other value be an option
for (perhaps the executor can capture that event)? Would you like
that?
Aparat from th
At 07:36 AM 4/15/2004 +0200, Thies C.Arntzen wrote:
Am 14.04.2004 um 21:53 schrieb Marcus Boerger:
Personally I'd much prefer a way of returning a value from a
constructor, i.e. to be able to 'return null;' or a similar language
construct so I could do 'if ($db = new SQLiteDatabase)'
It would als
On Apr 14, 2004, at 10:36 PM, Thies C.Arntzen wrote:
Am 14.04.2004 um 21:53 schrieb Marcus Boerger:
Personally I'd much prefer a way of returning a value from a
constructor, i.e. to be able to 'return null;' or a similar language
construct so I could do 'if ($db = new SQLiteDatabase)'
It would al
Am 14.04.2004 um 21:53 schrieb Marcus Boerger:
Personally I'd much prefer a way of returning a value from a
constructor, i.e. to be able to 'return null;' or a similar language
construct so I could do 'if ($db = new SQLiteDatabase)'
It would also mean that I would run into a 'calling method on a
n
Marcus Boerger wrote:
Hello Jani,
Wednesday, April 14, 2004, 3:35:23 AM, you wrote:
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 SQLiteDatab
> Marcus Boerger wrote:
>> In no language i know (c++, delphi, java as the popular ones) a ctor
>
> First of all I'm a bit sad that you compare PHP with 'old' static OO
> languages, not 'modern' dynamic ones like Python or Ruby. Wrong focus
> IMHO.
First of all, PHP's object model is most similar t
Marcus Boerger wrote:
In no language i know (c++, delphi, java as the popular ones) a ctor
First of all I'm a bit sad that you compare PHP with 'old' static OO
languages, not 'modern' dynamic ones like Python or Ruby. Wrong focus IMHO.
Second I don't think that's a very strong point: None of the
Hello Christian,
Wednesday, April 14, 2004, 2:31:12 PM, you wrote:
> Marcus Boerger wrote:
>> As i explained there is no good other way to tell the user the
>> ctor has failed. The two ways out out are:
> Personally I'd much prefer a way of returning a value from a
> constructor, i.e. to be abl
Sterling Hughes wrote:
Objects that have logic in a constructor throw exceptions - that's how it works.
I disagree. There *are* options to this approach as has been pointed out
earlier in this thread.
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://
The way to avoid exceptions in ctors is using empty exceptions and
issuing E_WARNINGs or E_ERRORs from every method when the instance
wansn't initialized already. If you think twise this is worse and
also comes along with a speed penalty from the additional checks.
Anyway if you don't want to deal
Marcus Boerger wrote:
As i explained there is no good other way to tell the user the
ctor has failed. The two ways out out are:
Personally I'd much prefer a way of returning a value from a
constructor, i.e. to be able to 'return null;' or a similar language
construct so I could do 'if ($db = new
Hello Jani,
Wednesday, April 14, 2004, 3:35:23 AM, you wrote:
> 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()
Hello Adam,
Wednesday, April 14, 2004, 7:36:43 AM, you wrote:
> 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
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
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
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
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, 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
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
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
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
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?"
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
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
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,
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 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
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 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
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
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: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, 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 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, 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 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,
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
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
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
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 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 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 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 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, 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 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, 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 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 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
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
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
1 - 100 of 109 matches
Mail list logo
