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 yo
== 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(). O
== Quote from Marcus Boerger ([EMAIL PROTECTED])'s article
> 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 wa
At 04:13 PM 2/16/2004 +, Stephane Drouard wrote:
> P.S. - BTW, why not call it IException (or ExceptionInterface) instead of
> Throwable? I think for people who don't know Java, it makes more sense.
Why not, but in that case, the other PHP interfaces should also follow
this naming convention.
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 o
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_)
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
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 reason
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
== 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
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 almos
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 thi
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
>> bac
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
>> curre
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
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
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
>
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
>
Hello Adam,
Sunday, February 15, 2004, 12:06:25 PM, Zeev Suraski wrote:
> 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 wa
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,
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
On 15 Feb 2004 at 13: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
ar
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 understan
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
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 thro
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
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 encountered
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 encountered a case where this isn't what I want, maybe in a
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 a
On Fri, 13 Feb 2004, Sterling Hughes wrote:
> > And my point is that I may want to create an exception (sterling's
> > 'InternalException', for example), that I do not want you catching
> > unless you specifically check for it.
>
> Right. Exception heirarchies are nice and all, but sometimes you
>
> 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 (su
>
> 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 se
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 languag
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 exc
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
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 every
Marcus Boerger wrote:
> If after all you need to override somthing then it is method toString()
Okay, I can live with that.
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/
37 matches
Mail list logo
