At 10:35 PM 2/16/2004 +0100, Timm Friebe wrote:
On Mon, 2004-02-16 at 09:35, Andi Gutmans wrote:
Hey,
Marcus didn't mean it adds complexity to the code but to PHP.
I can't see how it would: For those relying on the built-in base class,
it won't change a single thing.
For those wanting their own
== Quote from Marcus Boerger ([EMAIL PROTECTED])'s article
No those are read access members to private property members. When you lok
at the exception class:
php -r 'reflection_class::export(exception);'
then you'll encounter that you can overload __toString() and the
__construct(). Or in
Hello Stephane,
Tuesday, February 17, 2004, 10:57:02 AM, you wrote:
== Quote from Marcus Boerger ([EMAIL PROTECTED])'s article
No those are read access members to private property members. When you lok
at the exception class:
php -r 'reflection_class::export(exception);'
then you'll
Hey,
Marcus didn't mean it adds complexity to the code but to PHP. It's
obviously quite easy to implement this interface; implementation was never
a problem.
I don't really care too much if we have such an interface or not, although
I do think that it just makes things complex and I doubt
== Quote from Andi Gutmans ([EMAIL PROTECTED])'s article
Marcus didn't mean it adds complexity to the code but to PHP. It's
obviously quite easy to implement this interface; implementation was never
a problem.
I don't really care too much if we have such an interface or not, although
I do
Hello Stephane,
Monday, February 16, 2004, 5:13:46 PM, you wrote:
== Quote from Andi Gutmans ([EMAIL PROTECTED])'s article
Marcus didn't mean it adds complexity to the code but to PHP. It's
obviously quite easy to implement this interface; implementation was never
a problem.
I don't really
Marcus Boerger wrote:
as i said before there is a reason for that: I played a long time with
exceptions until they became what they are right now. And and attempt
to increase the visibility of one of its members can be used to make it
SEGV. So i don't want more visibility. Also where is the
Hello Ard,
Monday, February 16, 2004, 9:51:51 PM, you wrote:
Marcus Boerger wrote:
as i said before there is a reason for that: I played a long time with
exceptions until they became what they are right now. And and attempt
to increase the visibility of one of its members can be used to
On Mon, 2004-02-16 at 09:35, Andi Gutmans wrote:
Hey,
Marcus didn't mean it adds complexity to the code but to PHP.
I can't see how it would: For those relying on the built-in base class,
it won't change a single thing.
For those wanting their own exception (or to be more correct: _class_)
On Fri, 2004-02-13 at 18:54, Sterling Hughes wrote:
[...]
I get the concept, that's the reason Exception was added. But its meant
to be a voluntary thing (I believe this has been discussed before btw),
a standard class that gives users something to build upon, should they
want to. I think an
On Sat, 2004-02-14 at 11:38, Zeev Suraski wrote:
My experience is a bit of the opposite, and the truth is somewhere in the
middle I guess. But anyway, if you want to error out, why not just do
that? Why go through the mess of coming up with an exception that will
propagate through God
At 12:24 15/02/2004, Adam Bregenzer wrote:
On Sat, 2004-02-14 at 11:38, Zeev Suraski wrote:
My experience is a bit of the opposite, and the truth is somewhere in
the
middle I guess. But anyway, if you want to error out, why not just do
that? Why go through the mess of coming up with an
At 12:04 15/02/2004, Timm Friebe wrote:
I agree with Sterling. What if I have some really methods in my base
class that I rely on being existant in each and every subclass of it,
including Exception (or any other name I thought of to work around
Exception being built-in)?
Couldn't quite understand
On Sun, 2004-02-15 at 12:08, Zeev Suraski wrote:
At 12:04 15/02/2004, Timm Friebe wrote:
I agree with Sterling. What if I have some really methods in my base
class that I rely on being existant in each and every subclass of it,
including Exception (or any other name I thought of to work around
Hi Timm,
On Sun, 15 Feb 2004 12:53:21 +0100, Timm Friebe wrote:
As of B4, this is no longer possible. That's why i was agreeing to
Sterling in saying it should be optional to use the built-in exception
class. If there was a requirement to implement an interface (call it
Throwable, for
Hi Ard,
On Fri, 13 Feb 2004 18:45:51 +0100, Ard Biesheuvel wrote:
'Finally' is used for code that is executed anyway, whether an exception
has occurred or not. This is different from 'catch (...)' because the
catch clause is not executed if the try block exits with no eceptions.
Like
try
On Sun, Feb 15, 2004 at 04:12:08PM +0100, Marcus Boerger wrote:
Even if it were not the best solution it is still the solution that fits PHP
best and which is easiest to the developers. And as i said a while back the
current exception class allows several things a user implementation cannot
Ard, if the Exception class is not the base class of all exceptions(catch
all), it's very difficult to emulate finally(You must know every
exception that may be thrown inside the try block, and sometimes you
don't).
Of course, I was just stating that 'finally' != 'catch (...)', while
some of the
Hi Marcus,
On Sun, 15 Feb 2004 16:12:08 +0100, Marcus Boerger wrote:
Even if it were not the best solution it is still the solution that fits
PHP best and which is easiest to the developers. And as i said a while
back the current exception class allows several things a user
implementation
Hello Stefan,
Sunday, February 15, 2004, 4:32:21 PM, you wrote:
On Sun, Feb 15, 2004 at 04:12:08PM +0100, Marcus Boerger wrote:
Even if it were not the best solution it is still the solution that fits PHP
best and which is easiest to the developers. And as i said a while back the
current
Hello Cristiano,
Sunday, February 15, 2004, 4:37:37 PM, you wrote:
Hi Marcus,
On Sun, 15 Feb 2004 16:12:08 +0100, Marcus Boerger wrote:
Even if it were not the best solution it is still the solution that fits
PHP best and which is easiest to the developers. And as i said a while
back the
On Sun, 2004-02-15 at 16:09, Cristiano Duarte wrote:
Hi Timm,
[...]
IMHO, as you said, using an interface and letting the built-in class
implement it is the best approach. But only instances of classes wich
implement this interface should be throw or caught(language enforcement).
With this
At 19:50 13/02/2004, Sterling Hughes wrote:
Right. Exception heirarchies are nice and all, but sometimes you want
exceptions to leak through, or be explicitly caught. In-fact, I've
never encountered a case where this isn't what I want, maybe in a small
20 line example, but in large scripts I've
At 17:44 14/02/2004, George Schlossnagle wrote:
On Feb 14, 2004, at 8:08 AM, Zeev Suraski wrote:
At 19:50 13/02/2004, Sterling Hughes wrote:
Right. Exception heirarchies are nice and all, but sometimes you want
exceptions to leak through, or be explicitly caught. In-fact, I've
never
On Feb 13, 2004, at 11:35 AM, Adam Maccabee Trachtenberg wrote:
Andi's point, I believe, is that otherwise we'll need to add a
finally keyword to make sure some random extension doesn't throw
some random undocumented exception that you could miss. And I agree
with him. It just seems to make
George Schlossnagle wrote:
On Feb 13, 2004, at 11:35 AM, Adam Maccabee Trachtenberg wrote:
Andi's point, I believe, is that otherwise we'll need to add a
finally keyword to make sure some random extension doesn't throw
some random undocumented exception that you could miss. And I agree
with him.
At 08:12 AM 2/13/2004 -0500, Sterling Hughes wrote:
zeev Thu Feb 12 05:24:40 2004 EDT
Modified files:
/ZendEngine2 zend_default_classes.c zend_default_classes.h
zend_execute.h zend_execute_API.c
Log:
Exceptions updates:
- Enforce exceptions
At 08:51 AM 2/13/2004 -0500, George Schlossnagle wrote:
On Feb 13, 2004, at 8:39 AM, Andi Gutmans wrote:
At 08:12 AM 2/13/2004 -0500, Sterling Hughes wrote:
What is the reasoning for this new change?
The reasoning is that it allows users to do a catch-all (which otherwise
we'd add to the
On Feb 13, 2004, at 11:35 AM, Adam Maccabee Trachtenberg wrote:
Andi's point, I believe, is that otherwise we'll need to add a
finally keyword to make sure some random extension doesn't throw
some random undocumented exception that you could miss. And I agree
with him. It just seems to make
The reasoning is that it allows users to do a catch-all (which otherwise
we'd add to the language syntax). It also adds cleanliness to the Exception
hierarchy and allows PHP code to interact with PHP code which isn't written
by the developer knowing that there's a common interface (such
30 matches
Mail list logo
