Re: [PHP-DEV] Exceptions and Errors
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 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
> extension author should be allowed to choose (as long as he doesn't break
BC).
But the exception declarations ensure that you don't accidentally catch an
Exception in the wrong place, eg.
function add($amount)
{
add_money($amount) and log() or throw exception;
}
function move($amount)
{
$from->add(-$amount);
# It is *not* obvious here that this can fail and execution
# might stop here! Very dangerous!
$to->add($amount);
}
function transactions()
{
foreach ($transaction)
try { move($transaction->amount); } catch ...
}
You'd have to go function move($amount) throws SomeException, forcing
the developer to handle Exceptions at the soonest possible point...
(I'm a fan of it.)
Jevon
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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, that some extensions might benefit from exceptions and the
>> extension author should be allowed to choose (as long as he doesn't break
> BC).
> But the exception declarations ensure that you don't accidentally catch an
> Exception in the wrong place, eg.
> function add($amount)
> {
> add_money($amount) and log() or throw exception;
> }
> function move($amount)
> {
> $from->add(-$amount);
> # It is *not* obvious here that this can fail and execution
> # might stop here! Very dangerous!
> $to->add($amount);
> }
> function transactions()
> {
> foreach ($transaction)
> try { move($transaction->amount); } catch ...
> }
> You'd have to go function move($amount) throws SomeException, forcing
> the developer to handle Exceptions at the soonest possible point...
> (I'm a fan of it.)
That doesn't work in PHP or better say it doesn't make sense since many
things in PHP are done dynamically at runtime so there wouldn't be
compiletime exception declaration. Generally when i worked with declared
exceptions i hated the rare situations where an undeclared exception comes
into place because suddenly all your errorhandling is out of order. For
PHP this situation would be more or less the standard.
marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
> 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
> extension author should be allowed to choose (as long as he doesn't break
BC).
But the exception declarations ensure that you don't accidentally catch an
Exception in the wrong place, eg.
function add($amount)
{
add_money($amount) and log() or throw exception;
}
function move($amount)
{
$from->add(-$amount);
# It is *not* obvious here that this can fail and execution
# might stop here! Very dangerous!
$to->add($amount);
}
function transactions()
{
foreach ($transaction)
try { move($transaction->amount); } catch ...
}
You'd have to go function move($amount) throws SomeException, forcing
the developer to handle Exceptions at the soonest possible point...
(I'm a fan of it.)
Jevon
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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. Python methods can return false or null as much as PHP methods can. It might be a lot more _common_ to use exceptions but there are options. And the exception part is the one I don't like about Python anyway ;-) Still a ctor cannot return a value. Supporting this, if you look through the Python standard library you will see that exceptions are the employed method for handling constructor failures. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 > as much as PHP methods can. It might be a lot more _common_ to use > exceptions but there are options. And the exception part is the one I > don't like about Python anyway ;-) Still a ctor cannot return a value. marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 in the ctor. > There is nothing wrong with that at all, it's just the other "convert > errors to exceptions" stuff that bothers me :) Ah ok then. That is a thing that should be used with much much care! For that exact reason i used it only in SQLiteDatabase::__construct(). -- Best regards, Marcusmailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 other "convert errors to exceptions" stuff that bothers me :) Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 avoid exceptions for this simple case. The problem is that you would have to redefine basic understood oo concepts as implemented in php 5 at the moment. >> For example, in the SOAP extension it is very useful that in the >> SoapServer you can throw an exception and that'll create a SOAP error. >> Any other value you return will be the SOAP result. This is a perfect >> place for exceptions. > I tempted to challenge you to give me an example usage which I could > rewrite without exceptions, making it simpler and/or fixing problems ;-) > - Chris -- Best regards, Marcusmailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 logic. It's not that hard for the one in many classes where this >> might be needed. > He's FORCED to do this if extensions use this exception throwing from > constructors. Which is exactly his point here as we're now forcing > people to use this weird exception thing for no reason other than to > satisfy OO purists. Hey guys calm down on SQLite. There exceptions are better than handling errors here or leaving behind an invalid database object. ATM we don't have an option other than choosing between hell and hell or use exceptions. And also why do people discurage the use of exceptions that would never use oo in the first place? marcus -- Best regards, Marcusmailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 implemented SQLite's oo API exceptions are the way to go - a gingle exception in the ctor. >> 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 hope you meant "..that we should NOT make..".. >>saying, that some extensions might benefit from exceptions and the >>extension author should be allowed to choose (as long as he doesn't break BC). > And in case of SQLite, you still can (should work?) use the procedural > API and not worry about exceptions. Exactly! > (exception makes the rule? :) > --Jani -- Best regards, Marcusmailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 hope you meant "..that we should NOT make..".. >saying, that some extensions might benefit from exceptions and the >extension author should be allowed to choose (as long as he doesn't break BC). And in case of SQLite, you still can (should work?) use the procedural API and not worry about exceptions. (exception makes the rule? :) --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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. >>> >>> Then don't use them. You're a bit late to the party to debate their >> >> But if some extension (e.g. sqlite) forces you to use them? >> (yes, I can always use the non-OO-API, but still..) > ^ > >Yep. Or use it in the documented way. I don't see what the flap is >about. It's not mysterious. It's doc'd that constructors throw It's not that it's hard or mysterious, it just feels that exceptions are been pushed down the users throats, even when it (feels like it) shouldn't be necessary. >exceptions to signal failures. Refusal to use something in the >documented (and standard, as far as other OO-centric languages are >concerned) way solicits little sympathy from me. =) --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 simple case. For example, in the SOAP extension it is very useful that in the SoapServer you can throw an exception and that'll create a SOAP error. Any other value you return will be the SOAP result. This is a perfect place for exceptions. I tempted to challenge you to give me an example usage which I could rewrite without exceptions, making it simpler and/or fixing problems ;-) If you are inside a SOAP handler, nested inside a few functions and decide you want to fail, you can throw an exception instead of having to return an error all the way up the stack. 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 extension author should be allowed to choose (as long as he doesn't break BC). Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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();');
Seems to be an appropriately ugly BC hack for an appropriately issue to
begin with. So yes that will have to do then.
Thx for the hint.
regards,
Lukas Smith
[EMAIL PROTECTED]
___
BackendMedia
www.backendmedia.com
[EMAIL PROTECTED]
Linn Zwoch Smith GbR
Pariser Str. 44
D-10707 Berlin
Tel +49 30 83 22 50 00
Fax +49 30 83 22 50 07
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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();');
> > } else {
> > // error handling for PHP5
> > // user has to use the factory()/singleton() method
> > }
>
> I guess to make it clear, what I want is that PHP5 only explodes if it
> is actually asked to execute an assignement to $this and not just
> because there is one in the constructor. However Derick just messed
> around with the relevant code and didnt immediatly see a solution.
So what's wrong with using eval to evaluate the non-PHP5 compatible code?
Besides the performance penalty, of course. The code in the eval itself
will never be parsed or executed in PHP5. Seems to work for me at
least...
> regards,
> Lukas Smith
-Brad
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 But if some extension (e.g. sqlite) forces you to use them? (yes, I can always use the non-OO-API, but still..) ^ Yep. Or use it in the documented way. I don't see what the flap is about. It's not mysterious. It's doc'd that constructors throw exceptions to signal failures. Refusal to use something in the documented (and standard, as far as other OO-centric languages are concerned) way solicits little sympathy from me. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 you to use them? (yes, I can always use the non-OO-API, but still..) --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 exceptions, I'm always late, that's the story of my life :-) I realize that exceptions will stay in the language but that doesn't mean that extension writers should force me to use them. - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 has to use the factory()/singleton() method
}
I guess to make it clear, what I want is that PHP5 only explodes if it
is actually asked to execute an assignement to $this and not just
because there is one in the constructor. However Derick just messed
around with the relevant code and didnt immediatly see a solution.
regards,
Lukas Smith
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
[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 them as being rational then there's nothing I can do about it. Well, I suppose exceptions were added to the language for good reasons And I suppose they were added because they are fashionable. Luckily multiple inheritance and operator overloading are already out of fashion again, otherwise they would have been added to PHP5 as well. you simply do $foo=new Foo(); $foo->doThis(); $foo->doThat(); ... and your code will miserably fail in all but the naive case. For example when an exception happens it could be that doThis() was called but doThat() wasn't. That leads to problems big time. And yes, I have real worlds experience with this. Exceptions were added to be able to deal with error situations at the appropriate place (i.e. mostly for c) reasons). I recognize the goal but question the means. So it seems that you dislike exceptions because they don't solve problems they were not designed to solve for. Maybe your point is also that, with No, I dislike them because they create more problems than they solve. - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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=829
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 has to use the factory()/singleton() method
}
But this will obviously not work either. So I really see no way to
maintain BC for packages that have used this "feature" in PHP4.
Beyond that I also would like to go on record to say that just using OO
doesnt mean you necessary want or even know how to deal with exceptions.
And regarding logic in constructors its always problematic to start
shooting your users for using something that used to work. I think its
enough if we beat them with a stick for it. So I think for BC this
"mistake" or use of a feature that was never intended should not result
in such harsh BC issues.
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
> [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 and we should *not* make the same mistake with PHP. > (If anyone proposes inner classes in PHP then I'm outta here ;-)) Actually those are a 'modern/dynamic' aspect of Java (being pseudo-closures). >> "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 > as much as PHP methods can. It might be a lot more _common_ to use > exceptions but there are options. And the exception part is the one I > don't like about Python anyway ;-) There is no such thing as E_* in PHP, that is my point. All kind of exceptional behaviour is covered by exceptions. Anyway, I'd prefer to dicuss on objective, rational arguments than on pure personal preference. I really know you dislike exceptions by now ;) >> Well, your point before was that it's used only about 10 times per >> library. You shouldn't worry too much about 'heavy constructs', then. > > But I do. Because every single PHP programmer now has to learn this new > construct for no good reason. Well, I suppose exceptions were added to the language for good reasons (even if you don't like them, as stated several times). >> Well, you handle errors in each case. Exceptions just simplify non-local >> propagation of errors, so I fail to see your point. > > Non-local propagation of error is a bogus concept IMHO. Because it only > really works in academic examples, everywhere else it just complicated > things. I've seen many projects (both commercial and non-commercial ones) which successfully used exceptions. Also, I definately miss exceptions in PHP4. Manual propagation of error in my eyes is both error-prone, tedious and slow. >> Yeah. And well, people should be able to rely on the idea of 'new' not >> returning NULL (at least in the common cases, i.e. in the design of the > > But they now have to expect new to throw an exception. How is that any > better? Sorry, no *I* fail to see your point. It improves code maintainability. Instead of if(!$foo=new Foo()) return ERROR; if(!$foo->doThis()) return ERROR; if(!$foo->doThat()) return ERROR; you simply do $foo=new Foo(); $foo->doThis(); $foo->doThat(); And yes, I *intentionally* omitted try/catch clauses, as there is no error _handling_ in the original code, either. Just a lot of overhead from manual propagation of error. >> This is interesting. Do you have any explanations of the apparent >> failure >> of exceptions for you, or any suggestions on how to improve them (like, >> by > > The concept of non-local handling of errors means you > a) Handle errors where they happen. You don't need exceptions for that > b) Handle errors on a global level (i.e. die). Not feasible in a lot of > cases and you don't need exceptions here either > c) You handle errors somewhere inbetween. Exceptions were added to be able to deal with error situations at the appropriate place (i.e. mostly for c) reasons). > [...] > The same problem more or less applies if you use traditional error > handling (i.e. you would ignore the failure result code of add) but my > point is that exceptions _seem_ to help but don't. So it seems that you dislike exceptions because they don't solve problems they were not designed to solve for. Maybe your point is also that, with exceptions, people have to change their way of understanding code snippets (always have to have exception safety in mind). This is not much different from failing to catch today's error return values or E_RRORS, though. Cheers, Michael P.S.: Python supports overriding __new__, too (as a class method). P.P.S.: How about adding a new_ to the standard library (well it could be doable in userland, too, I guess) which catches exceptions and returns NULL in the exception case? This would be a generic 'new' wrapper for code which doesn't use exceptions (not that I think it would be necessary, but if people keep demanding it..). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 very useful that in the SoapServer you can throw an exception and that'll create a SOAP error. Any other value you return will be the SOAP result. This is a perfect place for exceptions. I tempted to challenge you to give me an example usage which I could rewrite without exceptions, making it simpler and/or fixing problems ;-) - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
[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 and we should *not* make the same mistake with PHP.
(If anyone proposes inner classes in PHP then I'm outta here ;-))
"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
as much as PHP methods can. It might be a lot more _common_ to use
exceptions but there are options. And the exception part is the one I
don't like about Python anyway ;-)
Well, your point before was that it's used only about 10 times per
library. You shouldn't worry too much about 'heavy constructs', then.
But I do. Because every single PHP programmer now has to learn this new
construct for no good reason.
Well, you handle errors in each case. Exceptions just simplify non-local
propagation of errors, so I fail to see your point.
Non-local propagation of error is a bogus concept IMHO. Because it only
really works in academic examples, everywhere else it just complicated
things.
Yeah. And well, people should be able to rely on the idea of 'new' not
returning NULL (at least in the common cases, i.e. in the design of the
But they now have to expect new to throw an exception. How is that any
better? Sorry, no *I* fail to see your point.
This is interesting. Do you have any explanations of the apparent failure
of exceptions for you, or any suggestions on how to improve them (like, by
The concept of non-local handling of errors means you
a) Handle errors where they happen. You don't need exceptions for that
b) Handle errors on a global level (i.e. die). Not feasible in a lot of
cases and you don't need exceptions here either
c) You handle errors somewhere inbetween.
Let's look at c): As soon as an exception is not handled at the level of
the caller or the method itself but passed through to a level higher up
you have to be damn careful not to end up with inconsistencies as the
caller function was only executed halfway.
Simplified example where I intentionally handle the exception one level
too high:
function add($amount)
{
add_money($amount) and log() or throw exception;
}
function move($amount)
{
$from->add(-$amount);
# It is *not* obvious here that this can fail and execution
# might stop here! Very dangerous!
$to->add($amount);
}
function transactions()
{
foreach ($transaction)
try { move($transaction->amount); } catch ...
}
The same problem more or less applies if you use traditional error
handling (i.e. you would ignore the failure result code of add) but my
point is that exceptions _seem_ to help but don't.
I'm sure people will not taking this example apart but I strongly
believe that for every solution using exceptions I can come up with a
traditional solution which is as easy to use and at least as safe.
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 > might be needed. He's FORCED to do this if extensions use this exception throwing from constructors. Which is exactly his point here as we're now forcing people to use this weird exception thing for no reason other than to satisfy OO purists. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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, Marcus Boerger wrote:
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 that there were other possible solutions mentioned so
far:
The factory solution prevents inheritance on overloaded objects.
If it would work the derived class needs to somehow be able to
create a derived instance and still use the inherited factory from
its derived factory. That is it somehow needs to tell the inherited
factory which class entry to use.
Overriding new could be a solution for php 5.1:
class SQLiteDatabase {
// Suppose __new gets executed right after the object
// was created and contains the only reference to the
// newly created object in its first parameter. And
// let it return the instance or NULL. New obviously
// needs to be static.
// A small side-problem: __new must not be called from
// any other place than new.
static function __new($instance) {
if ($instance->ctorOk()) {
return $instance;
} else {
return NULL;
}
}
private function ctorOk() {
// just verify the object state once in __new
}
}
Another __new solution would be to let it execute the real
allocating "new" itself (more like c++ and others) how would
we differentiate those two news now? Anywhere i suggest the
code looking something like this:
static function new($file /* params from the new call*/) {
$instance = new SQLiteDatabase($file);
if ($instance->ctorOk()) {
return $instance;
} else {
return NULL;
}
}
Also the above second new solution has again the inheritance
problem: Every derived class would have to overwrite __new or
we need a dynamic allocating new and pass the requested class
to it:
static function new($class, $file) {
$instance = new $class($file);
if ($instance->ctorOk()) {
return $instance;
} else {
return NULL;
}
}
Any ideas from you Thies?
best regards
marcus
Thursday, April 15, 2004, 7:36:46 AM, you 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 also mean that I would run into a 'calling method on a
>>> non-object' error if I don't check it (which is fine).
>>
>> In no language i know (c++, delphi, java as the popular ones) a ctor
>> can return a value especially not it's own value. The problem is that
>> when the ctor is called the object is already created. For most
>> languages
>> that means some memory has been allocated and for php overloaded
>> objects
>> like the SQLite class it also means that the memory has been
>> initialized.
>>
>> Now in PHP 4 there was the ugly trick of setting "$this=NULL".
>>
> i'm sure ZE2 can be tricked to support "return NULL" from a constructor
> so that:
> $a = new bla();
> if (! $a) ...
> 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 of pre-requisites for
> learning/using php would just be a poor decision looking at what made
> php as popular as it is today.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 of pre-requisites for >> learning/using php would just be a poor decision looking at what made >> php as popular as it is today. > the solution there would not be to "fix" ctor, but instead to use a > factory, and have constructors without logic. the other case where one > can't live without exceptions is when using overloads (solution: don't > use overloads when you care about signaling error conditions). > couldn't agree more btw, i think exceptions are cool, and certainly > have their usages, but after reading the comments on this thread, i > think we are about to hand out cocaine to children. hopefully one hit > is enough ;-) > either way its rc2, not much can be done now... When i started the OO model of SQLite i explicitly choose ctors with logic over the factory attempt because the latter prevents inheritance from the beginning at least in the case of overloaded php objects. regards marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 that there were other possible solutions mentioned so
far:
The factory solution prevents inheritance on overloaded objects.
If it would work the derived class needs to somehow be able to
create a derived instance and still use the inherited factory from
its derived factory. That is it somehow needs to tell the inherited
factory which class entry to use.
Overriding new could be a solution for php 5.1:
class SQLiteDatabase {
// Suppose __new gets executed right after the object
// was created and contains the only reference to the
// newly created object in its first parameter. And
// let it return the instance or NULL. New obviously
// needs to be static.
// A small side-problem: __new must not be called from
// any other place than new.
static function __new($instance) {
if ($instance->ctorOk()) {
return $instance;
} else {
return NULL;
}
}
private function ctorOk() {
// just verify the object state once in __new
}
}
Another __new solution would be to let it execute the real
allocating "new" itself (more like c++ and others) how would
we differentiate those two news now? Anywhere i suggest the
code looking something like this:
static function new($file /* params from the new call*/) {
$instance = new SQLiteDatabase($file);
if ($instance->ctorOk()) {
return $instance;
} else {
return NULL;
}
}
Also the above second new solution has again the inheritance
problem: Every derived class would have to overwrite __new or
we need a dynamic allocating new and pass the requested class
to it:
static function new($class, $file) {
$instance = new $class($file);
if ($instance->ctorOk()) {
return $instance;
} else {
return NULL;
}
}
Any ideas from you Thies?
best regards
marcus
Thursday, April 15, 2004, 7:36:46 AM, you 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 also mean that I would run into a 'calling method on a
>>> non-object' error if I don't check it (which is fine).
>>
>> In no language i know (c++, delphi, java as the popular ones) a ctor
>> can return a value especially not it's own value. The problem is that
>> when the ctor is called the object is already created. For most
>> languages
>> that means some memory has been allocated and for php overloaded
>> objects
>> like the SQLite class it also means that the memory has been
>> initialized.
>>
>> Now in PHP 4 there was the ugly trick of setting "$this=NULL".
>>
> i'm sure ZE2 can be tricked to support "return NULL" from a constructor
> so that:
> $a = new bla();
> if (! $a) ...
> 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 of pre-requisites for
> learning/using php would just be a poor decision looking at what made
> php as popular as it is today.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 also mean that I would run into a 'calling method on a non-object' error if I don't check it (which is fine). In no language i know (c++, delphi, java as the popular ones) a ctor can return a value especially not it's own value. The problem is that when the ctor is called the object is already created. For most languages that means some memory has been allocated and for php overloaded objects like the SQLite class it also means that the memory has been initialized. Now in PHP 4 there was the ugly trick of setting "$this=NULL". i'm sure ZE2 can be tricked to support "return NULL" from a constructor so that: $a = new bla(); if (! $a) ... 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 of pre-requisites for learning/using php would just be a poor decision looking at what made php as popular as it is today. In order to use them wisely you need to be an advanced programmer. Personally, I must say that when exceptions are used correctly (and some of the comments on this list make me think that some of the people here used them incorrectly), then I think they are extremely useful. I don't think allowing the return of anything except for the object itself is *fixing* PHP. Anyway, you don't have to put logic in the constructor. I am fine with not forcing people to use exceptions. However, I am also fine that some of the OO extensions who wish to use exceptions use them. For example, in the SOAP extension it is very useful that in the SoapServer you can throw an exception and that'll create a SOAP error. Any other value you return will be the SOAP result. This is a perfect place for exceptions. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 also mean that I would run into a 'calling method on a non-object' error if I don't check it (which is fine). In no language i know (c++, delphi, java as the popular ones) a ctor can return a value especially not it's own value. The problem is that when the ctor is called the object is already created. For most languages that means some memory has been allocated and for php overloaded objects like the SQLite class it also means that the memory has been initialized. Now in PHP 4 there was the ugly trick of setting "$this=NULL". i'm sure ZE2 can be tricked to support "return NULL" from a constructor so that: $a = new bla(); if (! $a) ... 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 of pre-requisites for learning/using php would just be a poor decision looking at what made php as popular as it is today. the solution there would not be to "fix" ctor, but instead to use a factory, and have constructors without logic. the other case where one can't live without exceptions is when using overloads (solution: don't use overloads when you care about signaling error conditions). couldn't agree more btw, i think exceptions are cool, and certainly have their usages, but after reading the comments on this thread, i think we are about to hand out cocaine to children. hopefully one hit is enough ;-) either way its rc2, not much can be done now... -sterling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 non-object' error if I don't check it (which is fine). In no language i know (c++, delphi, java as the popular ones) a ctor can return a value especially not it's own value. The problem is that when the ctor is called the object is already created. For most languages that means some memory has been allocated and for php overloaded objects like the SQLite class it also means that the memory has been initialized. Now in PHP 4 there was the ugly trick of setting "$this=NULL". i'm sure ZE2 can be tricked to support "return NULL" from a constructor so that: $a = new bla(); if (! $a) ... 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 of pre-requisites for learning/using php would just be a poor decision looking at what made php as popular as it is today. thies -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 SQLiteDatabase();
$db = sqlite_open();
The first is fatal; the second isn't.
So to use the OO API of sqlite requires that I use
exceptions with it too..? It's pretty unfriendly to force
the use of exceptions like this, IMO.
As i explained there is no good other way to tell the user the
ctor has failed. The two ways out out are:
1) Using empty ctors and check whetehr the instance is initialized
on every method call which is slower and different from our other
objects.
2) Pass another parameter by reference '&$failed' which will hold
the state of the ctor execution. Still you need to solve the
now illegal instance which pretty much leads to 1.
don't forget
3) Use a factory method and an empty constructor
$db = new SQLiteDatabase::factory();
if (!$db) {
// handle error
}
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
> 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 to the Java one, so
Markus' comparisons make most sense in my eyes.
Anyway, you asked for comparisons with modern, dynamic languages:
Python: "As a special constraint on constructors, no value may be
returned; doing so will cause a TypeError to be raised at runtime." [1]
Ruby: Thanks to friendly assistance in freenode's #ruby-lang, I can report
that it is possible (and simple) to override 'new' by simply defining a
'new' class method.
Smalltalk: (similar to Ruby)
Common Lisp: It is possible in CL aswell, by overriding MAKE-INSTANCE.
Anyway, notice that each of those languages have much larger dynamicity
than PHP and its object model. For instance, it's possible to redefine
methods, to alter object methods at runtime, the classes themselves are
objects, too. I.e. to repeat what I said above, comparing PHP's OO model
with Java's is much more 'on focus' than comparing it with "modern
dynamic" languages.
> Second I don't think that's a very strong point: None of the mentioned
> languages have the notion of a method __call either (not sure about
> Delphi). It's fine to copy from other languages but that doesn't mean
> that you cannot find better ways of doing things.
Alright, but there's also a certain focus or idea behind the current
object model. And not only in the object model of PHP, Java and C++, but
also in Python, Ruby, Common Lisp and Smalltalk it's most common to throw
an exception from the constructor (it's especially odd that you refer to
"modern dynamic" languages in that context, as for instance in Python
there is no error handling but by using exceptions).
>> If you ask me i am pretty fine with (otherwise i wouldn't have made it
>> so):
>> try {
>> $db = new SQLiteDatabase($file);
>> }
>> catch (Exception $e) {
>
> If this is the *only* place in my whole application where I use
> try/catch I'd rather have another way of doing it. It's much to heavy a
> construct for this single case.
Well, your point before was that it's used only about 10 times per
library. You shouldn't worry too much about 'heavy constructs', then.
>> try {
>> // some control code here: start-ob,
>> error-handler-that-throws-exceptions
>> $db = new SQLiteDatabase($file);
>> // your normal code **without a single error-handling-if**
>> }
>
> Have you ever really used exceptions? What you're proposing is nothing
> better than set_error_handler on a global level. If you use exceptions
> all over your application though you quickly make things much more
> complicated, e.g. you need a DB with transactions (goodbye MySQL),
> otherwise you will end up with inconsistent DB states. And that's just
> the tip of the iceberg. Trust me, I've been there.
Well, you handle errors in each case. Exceptions just simplify non-local
propagation of errors, so I fail to see your point.
>> It not only has to be done in your PHP script but also internally at
>> several
>> more places. So for me this is no option.
>
> If you could give me back a null pointer that wouldn't be a problem.
> Otherwise you need one bit per object stating if it is valid. And one
> line per user-visible method. I don't think that's asked too much.
> You're writing this code once but it will be used thousands of times.
Yeah. And well, people should be able to rely on the idea of 'new' not
returning NULL (at least in the common cases, i.e. in the design of the
'standard library'), I think. Not even C++ does return 0 from 'new' (by
default :).
>> Me too, i use both where appropriate.
>
> Same here with the difference that I still haven't found where
> exceptions are appropriate yet (-:C
This is interesting. Do you have any explanations of the apparent failure
of exceptions for you, or any suggestions on how to improve them (like, by
making them resumable as in CL, or by generalizing them into first-class
continuations)?
Cheers,
Michael
[1] http://www.python.org/doc/current/ref/customization.html
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 mentioned
languages have the notion of a method __call either (not sure about
Delphi). It's fine to copy from other languages but that doesn't mean
that you cannot find better ways of doing things.
If you ask me i am pretty fine with (otherwise i wouldn't have made it so):
try {
$db = new SQLiteDatabase($file);
}
catch (Exception $e) {
If this is the *only* place in my whole application where I use
try/catch I'd rather have another way of doing it. It's much to heavy a
construct for this single case.
try {
// some control code here: start-ob, error-handler-that-throws-exceptions
$db = new SQLiteDatabase($file);
// your normal code **without a single error-handling-if**
}
Have you ever really used exceptions? What you're proposing is nothing
better than set_error_handler on a global level. If you use exceptions
all over your application though you quickly make things much more
complicated, e.g. you need a DB with transactions (goodbye MySQL),
otherwise you will end up with inconsistent DB states. And that's just
the tip of the iceberg. Trust me, I've been there.
It not only has to be done in your PHP script but also internally at several
more places. So for me this is no option.
If you could give me back a null pointer that wouldn't be a problem.
Otherwise you need one bit per object stating if it is valid. And one
line per user-visible method. I don't think that's asked too much.
You're writing this code once but it will be used thousands of times.
Me too, i use both where appropriate.
Same here with the difference that I still haven't found where
exceptions are appropriate yet (-:C
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 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
> non-object' error if I don't check it (which is fine).
In no language i know (c++, delphi, java as the popular ones) a ctor
can return a value especially not it's own value. The problem is that
when the ctor is called the object is already created. For most languages
that means some memory has been allocated and for php overloaded objects
like the SQLite class it also means that the memory has been initialized.
Now in PHP 4 there was the ugly trick of setting "$this=NULL".
To know how that worked you need to deeply understand PHP's GC. During
ctor execution $this is the only reference to the newly created instance.
Hence setting "$this=NULL" reduces the refcount to zero what deallocates
the object by calling it's ctor. The problem with this is that it could
never work correctly because evern after setting "$this=NULL" you still
need to be able to rely on a valid $this which you obviously can't.
> I strongly believe that we are talking about some basic initialization
> stuff to be done at the beginning of an application like creating a DB
> connection and setting up some environment only. Otherwise you'd imply
> that you start try/catching on every object instantation which is
> definitely not the way to go!
If you ask me i am pretty fine with (otherwise i wouldn't have made it so):
try {
$db = new SQLiteDatabase($file);
}
catch (Exception $e) {
// Code for no db-connection
exit(0);
}
// other code
And if you don't need code for "no-db-connection", well then you do not need
the try-catch-block at all. It is just a bit more typing you get used to
once you have learned it. And for me it is much better then having to use
an if-clause for every member access.
Maybe it is important to notice which internal objects may throw an
exception on failure.
On the otherhand it is possible to convert all warnings to exceptions in
user scripts. Together with the ability to control outpu buffering this is
a great gift:
try {
// some control code here: start-ob, error-handler-that-throws-exceptions
$db = new SQLiteDatabase($file);
// your normal code **without a single error-handling-if**
}
catch (Exception $e) {
// clear-ob
// Code for no db-connection
exit(0);
}
> Alternatively (something which works for PHP4 already) one could simply
> have a status a la
> $db = new SQLiteDatabase;
> if ($db->isValid)
> which is less elegant but based on the assumption that it has to be done
> at most 10 times in an application works just as well.
It not only has to be done in your PHP script but also internally at several
more places. So for me this is no option.
> In my opinion exceptions-for-ctor-failure is already a work-around
> abusing exceptions in an at least arguable way. You _require_ users to
> learn about a whole new (and complicated) paradigm in error handling
> which I'd very much avoid.
>> Hey if you want to work with OO then deal with all OO issues or
>> create ugly workarounds and don't pretend the language is OO at
> OO works very well without exceptions. Exceptions has to do with error
> handling, not with data encapsulation (which OO is about).
> Yes, I like OO. No I don't like exceptions. And I worked with both.
Me too, i use both where appropriate.
--
Best regards,
Marcusmailto:[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 with exceptions in ctors then you probably might not want to deal with oo at all. What marcus said. Also, I want the record to state that I'm not anti-exceptions. Neither, I guess is marcus. Both of us just prefer people use them appropriately, within well known mappings and usage cases for exceptions. Objects that have logic in a constructor throw exceptions - that's how it works. Same thing for overloads. These are not revolutionary concepts, but pretty standard OO paradigms. In the same vein, many things that aren't exceptions are handled by E_WARNING and E_ERROR. If someone who understands exceptions wants to use them in an acceptable (and by this, I mean a manner that won't make someone with experience with OO paradigms go "what *is* he or she smoking?"), then they should be free to do so in standard PHP extensions (imho). But as for converting such things, please, let's leave well-enough alone. -Sterling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 SQLiteDatabase)' It would also mean that I would run into a 'calling method on a non-object' error if I don't check it (which is fine). I strongly believe that we are talking about some basic initialization stuff to be done at the beginning of an application like creating a DB connection and setting up some environment only. Otherwise you'd imply that you start try/catching on every object instantation which is definitely not the way to go! Alternatively (something which works for PHP4 already) one could simply have a status a la $db = new SQLiteDatabase; if ($db->isValid) which is less elegant but based on the assumption that it has to be done at most 10 times in an application works just as well. In my opinion exceptions-for-ctor-failure is already a work-around abusing exceptions in an at least arguable way. You _require_ users to learn about a whole new (and complicated) paradigm in error handling which I'd very much avoid. Hey if you want to work with OO then deal with all OO issues or create ugly workarounds and don't pretend the language is OO at OO works very well without exceptions. Exceptions has to do with error handling, not with data encapsulation (which OO is about). Yes, I like OO. No I don't like exceptions. And I worked with both. - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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(); >>> $db = sqlite_open(); >> >>> The first is fatal; the second isn't. > So to use the OO API of sqlite requires that I use > exceptions with it too..? It's pretty unfriendly to force > the use of exceptions like this, IMO. As i explained there is no good other way to tell the user the ctor has failed. The two ways out out are: 1) Using empty ctors and check whetehr the instance is initialized on every method call which is slower and different from our other objects. 2) Pass another parameter by reference '&$failed' which will hold the state of the ctor execution. Still you need to solve the now illegal instance which pretty much leads to 1. Hey if you want to work with OO then deal with all OO issues or create ugly workarounds and don't pretend the language is OO at all. And after all exceptions can have a nice benefit. -- Best regards, Marcusmailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 = new SQLiteDatabase(); >> > $db = sqlite_open(); >> >> sqlite_open returns a resource and new SQLiteDatabase returns an object. >> The latter is a ctor and to prevent it throwing exceptions you'd need to >> provide a factory method, make the ctor private (which prevents inhering) >> and then look ofr all possible kinds of failures before calling the ctor. > I understand the differences between the two. However, I believe that > most people view these two actions as identical. In their minds, the > only difference is whether they're using a procedural or OO API to > create a connection. > I realize, for current technical reasons, ctors need to throw > exceptions; however, the end result is that changing from one API to > another ends up turning a failed database connection from a harmless > warning to a fatal error. > This seems bad because it's not an obvious side effect. Additionally, > given the current anti-exception sentiment on this list, it also seems > odd to essentially require all object instantiations (but only > instantiations) to be wrapped inside a try/catch block, or risk an > immediate script termination. > Is there anything we can do to preserve the ability to alert > developers to errors during the construction process without also > forcing them to catch exceptions? 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 with exceptions in ctors then you probably might not want to deal with oo at all. marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 a resource and new SQLiteDatabase returns an object. > The latter is a ctor and to prevent it throwing exceptions you'd need to > provide a factory method, make the ctor private (which prevents inhering) > and then look ofr all possible kinds of failures before calling the ctor. I understand the differences between the two. However, I believe that most people view these two actions as identical. In their minds, the only difference is whether they're using a procedural or OO API to create a connection. I realize, for current technical reasons, ctors need to throw exceptions; however, the end result is that changing from one API to another ends up turning a failed database connection from a harmless warning to a fatal error. This seems bad because it's not an obvious side effect. Additionally, given the current anti-exception sentiment on this list, it also seems odd to essentially require all object instantiations (but only instantiations) to be wrapped inside a try/catch block, or risk an immediate script termination. Is there anything we can do to preserve the ability to alert developers to errors during the construction process without also forcing them to catch exceptions? -adam -- [EMAIL PROTECTED] author of o'reilly's php cookbook avoid the holiday rush, buy your copy today! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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. So to use the OO API of sqlite requires that I use exceptions with it too..? It's pretty unfriendly to force the use of exceptions like this, IMO. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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
>> E_ERRORs. Just have an uncaught exception message as we have now.
>> And no way of generous catching E_ERRORs by back-door.
> This is what I meant. An uncaught exception message is fatal right
> now.
Not really. The exception is caught by the engine and presented as a
E_ERROR after execution has finished. If that still allows for
user-back-door-catching then we have to fix that. The only exception from
that is again soap.
> PHP Fatal error: Uncaught exception 'SQLiteException' with message
> 'SQLiteDatabase::__construct(): unable to open database: /sbin/foo'
> in Command line code:1
> Stack trace:
> #0 {main}
> thrown in Command line code on line 1
> 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.
> -adam
--
Best regards,
Marcusmailto:[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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
>> E_ERRORs. Just have an uncaught exception message as we have now.
>> And no way of generous catching E_ERRORs by back-door.
> This is what I meant. An uncaught exception message is fatal right
> now.
> PHP Fatal error: Uncaught exception 'SQLiteException' with message
> 'SQLiteDatabase::__construct(): unable to open database: /sbin/foo'
> in Command line code:1
> Stack trace:
> #0 {main}
> thrown in Command line code on line 1
> 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 a resource and new SQLiteDatabase returns an object.
The latter is a ctor and to prevent it throwing exceptions you'd need to
provide a factory method, make the ctor private (which prevents inhering)
and then look ofr all possible kinds of failures before calling the ctor.
--
Best regards,
Marcusmailto:[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
> 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 that > violates the general exception idea (see Stanislav's mail on local stack > corruption...). Java has the concept of an "Error" (extended from Throwable which is extended to be Exception too) which "indicates serious problems that a reasonable application should not try to catch. Most such errors are abnormal conditions." Perhaps normal E_ERROR => Exception, and totally fatal errors => Error. You can catch Errors too, but it's specifically said that you really shouldn't try. Jevon -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 no way of generous catching E_ERRORs by back-door.
This is what I meant. An uncaught exception message is fatal right
now.
PHP Fatal error: Uncaught exception 'SQLiteException' with message
'SQLiteDatabase::__construct(): unable to open database: /sbin/foo'
in Command line code:1
Stack trace:
#0 {main}
thrown in Command line code on line 1
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.
-adam
--
[EMAIL PROTECTED]
author of o'reilly's php cookbook
avoid the holiday rush, buy your copy today!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 modify E_ERRORs to be >> > non-fatal. >> >> Not at the moment. > Ah. Okay. I guess I was confused by: >> 1) convert the non continuable E_ERRORs to a higher severity (if there >> are any at all) > So what you're saying is that some problems that are classified (by a > developer) as E_ERRORs aren't actually fatal to PHP even though right > now PHP treats them as such. (Like an E_ERROR for passing the wrong > number of parameters to a function.) 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 that violates the general exception idea (see Stanislav's mail on local stack corruption...). > But, since these problems are probably still "very bad," they're the > type of errors that are best handled by exceptions. After having all E_ERRORs theoretical recoverable there might be places where exceptions are better than actual E_ERRORs. > Therefore, you propose to promote non-recoverable errors to E_FATAL > (or whatever) and keep the recoverable E_ERRORs where they are. Exact so far. > Then, > when an E_ERROR occurs, it's thrown as an exception? (I'm not sure if > you're saying this.) Only where needed (e.g. the extension developer wants to). For me 'where needed) includes ctor failure as mentioned before - SQLite does so. > 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 no way of generous catching E_ERRORs by back-door. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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
Re: [PHP-DEV] Exceptions and Errors
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
Re: [PHP-DEV] Exceptions and Errors
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 important to note that this is now technically feasible but not (yet) part of PHP. (You can actually do it as an extension though. :) Okay, so it's just an unenabled feature, not an impossible one. :) Uncommitted, technically. I have a patch against an old ZE2 build lying around and the extension version is in chap 23 of my book. For the type of error in question consider this: this is fatal in PHP, but can be completely recoverable from an engine-consistency standpoint. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 feasible but not > (yet) part of PHP. (You can actually do it as an extension though. :) Okay, so it's just an unenabled feature, not an impossible one. :) > > If these types of errors are now recoverable, shouldn't we let the > > programmer decide how they want to handle them? > > You could, but you'ld break existing scripts that rely on E_ERROR being > fatal in PHP4-ish code. Since exceptions don't exist in PHP4, using > them to avoid previously fatal errors doesn't alter any existing > behavior. Right. This makes sense. Nobody wants to fix up old programs because they died in PHP 4, but live in PHP 5. That's a waste of time, compared to adding another error level. -adam -- [EMAIL PROTECTED] author of o'reilly's php cookbook avoid the holiday rush, buy your copy today! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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. I guess I was confused by: > 1) convert the non continuable E_ERRORs to a higher severity (if there > are any at all) So what you're saying is that some problems that are classified (by a developer) as E_ERRORs aren't actually fatal to PHP even though right now PHP treats them as such. (Like an E_ERROR for passing the wrong number of parameters to a function.) But, since these problems are probably still "very bad," they're the type of errors that are best handled by exceptions. Therefore, you propose to promote non-recoverable errors to E_FATAL (or whatever) and keep the recoverable E_ERRORs where they are. Then, when an E_ERROR occurs, it's thrown as an exception? (I'm not sure if you're saying this.) If the developer catches it, they handle it. If they don't, PHP catches it and issues a fatal error. -adam -- [EMAIL PROTECTED] author of o'reilly's php cookbook avoid the holiday rush, buy your copy today! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 extension though. :) If these types of errors are now recoverable, shouldn't we let the programmer decide how they want to handle them? You could, but you'ld break existing scripts that rely on E_ERROR being fatal in PHP4-ish code. Since exceptions don't exist in PHP4, using them to avoid previously fatal errors doesn't alter any existing behavior. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 the process. >> >> This is a huge bc break. Raising the severity on non-continuable >> errors and throwing exceptions for E_ERRORs produces no bc issues. > I'm confused about the warning levels. I guess it's best if I talk > this out in an e-mail. :) > 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. > However, even with exceptions, some errors should still be > considered fatal. > We have some choices: > 1) Promote those few "truly fatal" errors to something else, like >E_FATAL. Current E_ERRORs remain fatal, unless (now) caught by a >catch() block. > 2) Demote "recoverable E_ERRORS" to E_WARNING. Things that are E_ERROR >are always fatal regardless of exception handling. > 3) Something else, yet to be proposed. > I guess I'm confused about why some E_ERRORs are now able to be > handled in userland, but only by using exceptions. If these types of > errors are now recoverable, shouldn't we let the programmer decide how > they want to handle them? > -adam > -- > [EMAIL PROTECTED] > author of o'reilly's php cookbook > avoid the holiday rush, buy your copy today! -- Best regards, Marcusmailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 non-continuable > errors and throwing exceptions for E_ERRORs produces no bc issues. I'm confused about the warning levels. I guess it's best if I talk this out in an e-mail. :) 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. However, even with exceptions, some errors should still be considered fatal. We have some choices: 1) Promote those few "truly fatal" errors to something else, like E_FATAL. Current E_ERRORs remain fatal, unless (now) caught by a catch() block. 2) Demote "recoverable E_ERRORS" to E_WARNING. Things that are E_ERROR are always fatal regardless of exception handling. 3) Something else, yet to be proposed. I guess I'm confused about why some E_ERRORs are now able to be handled in userland, but only by using exceptions. If these types of errors are now recoverable, shouldn't we let the programmer decide how they want to handle them? -adam -- [EMAIL PROTECTED] author of o'reilly's php cookbook avoid the holiday rush, buy your copy today! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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. >> Too much exception is a bad thing anyway. > Yes, it has to be a really severe error, otherwise you start putting > try/catch everywhere making your code ugly and your error handling > unmaintainable. > We should try to help people resist the temptation of exceptions as they > are a dangerous thing if not used very wisely (-:C Yep! Respect these rules 1) Exceptions are exceptions 2) Never use exceptions for control flow 3) Never ever use exceptions for parameter passing -- Best regards, Marcusmailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 back that E_ERRORs shouldn't be >> > converted to exceptions because of a few E_ERRORs that might not be >> > continuable. From my point of view we should do two things: >> > 1) convert the non continuable E_ERRORs to a higher severity (if there are >> >any at all) >> >> Is there a reason not to move non-continuable E_ERRORs to E_WARNINGs? > Yes, as E_WARNINGs are supposed to be continuable in PHP, unlike > E_ERROR. You mean PHP 4 here. And that's the problem, in PHP 5 we have excpetions that provide a way to handle most every E_ERROR more generous. The question now is do we want to provide this to the user? -- Best regards, Marcusmailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 because of a few E_ERRORs that might not be continuable. From my point of view we should do two things: 1) convert the non continuable E_ERRORs to a higher severity (if there are any at all) 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 non-continuable errors and throwing exceptions for E_ERRORs produces no bc issues. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 few E_ERRORs that might not be > > continuable. From my point of view we should do two things: > > 1) convert the non continuable E_ERRORs to a higher severity (if there are > >any at all) > > Is there a reason not to move non-continuable E_ERRORs to E_WARNINGs? Yes, as E_WARNINGs are supposed to be continuable in PHP, unlike E_ERROR. regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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, otherwise you start putting try/catch everywhere making your code ugly and your error handling unmaintainable. We should try to help people resist the temptation of exceptions as they are a dangerous thing if not used very wisely (-:C - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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. From my point of view we should do two things: > 1) convert the non continuable E_ERRORs to a higher severity (if there are >any at all) 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. > 2) Use exceptions when a ctor needs to advertise its failure and in other >places where exceptions are really usefull. > > Too much exception is a bad thing anyway. There's so much anti-exception sentiment on this list, I wonder how they ever made it into PHP 5 in the first place. :) But, seriously, besides for ctors, when do people here expect developers to use exceptions? -adam -- [EMAIL PROTECTED] author of o'reilly's php cookbook avoid the holiday rush, buy your copy today! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 enough to need them. >> Unfortunately, many developers I have talked to about exceptions plans >> to use them for just about every kind of error condition, and they >> expect them to be useful as such. > 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. 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. 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. From my point of view we should do two things: 1) convert the non continuable E_ERRORs to a higher severity (if there are any at all) 2) Use exceptions when a ctor needs to advertise its failure and in other places where exceptions are really usefull. Too much exception is a bad thing anyway. -- Best regards, Marcusmailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 php_set_error_handling(error_handling_t error_handling, zend_class_entry
*exception_class TSRMLS_DC);
#define php_std_error_handling() php_set_error_handling(EH_NORMAL, NULL TSRMLS_CC)
php_set_error_handling(() sets the mode and class_entry.
php_std_error_handling() resets the mode and class entry.
EH_NORMAL => Standard behavior = no exceptions
EH_SUPPRESS => Neither throw an exception nor show/log the error
EH_THROW=> Throw an exception if no excpetion is pending
If exception_class == NULL then a standard exception will be
generated.
Monday, April 12, 2004, 11:31:46 PM, you wrote:
> 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
>> }
>> } catch {
>> // handle exception
>> }
>>
>>It's really crazy to need to mix both types of error handling within
>>the same block of code.
--
Best regards,
Marcusmailto:[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 extended to exceptions. It's supposed to be a policy, it was discussed some (long) time ago. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 and if used poorly makes things *really* messy. Even after developing Java for over one year (with 10 years of programming experience in other languages) I was still not at the level where I could decide where to throw and where to catch exceptions without serious evaluation of the system. New concepts (like PPP and exceptions) might be valuable in some contexts but they are _not easy_ to use and the common PHP developer *MUST NOT* be forced to use them. You might think I'm kidding about PPP being hard but believe me: Using the right access level for methods is not trivial as soon as you build a framework and then both use and extend it. PPP and exceptions are *not* required to write even medium size applications (several 10k of lines), only DoD-style environments should _enforce_ such mechanisms. > 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 extended to exceptions. My .02 CHF, - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 - "somettthing so bad happened that there's no point to continue locally - the current task has failed beyond repair". If the caller of the task thinks that this sub-task failure is not that bad and the top-level task can still go on, it catches the exception and handles it. >From this point of view, I would use exceptions only to signal a very serious error condition - e.g., for DB library it would be DB connection missing (since it is not likely for any function to work after that), etc. GB>>if continue or return was extended to allow returning from a catch to GB>>the point of execution after the throw statement, this would of course GB>>open a can of worms, but it might solve the issue. Obviously this would I don't think it's possible. Exceptions unroll the stack, and once it's unrolled, you can't re-roll it back there. It just doesn't exist anymore. And we don't really want to enter the domain of context-switches inside PHP. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.109 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 to about exceptions plans > to use them for just about every kind of error condition, and they > expect them to be useful as such. 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. 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. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 (which can be recovered from) to exceptions, functionally this would not be very problematic because for people not using exceptions they'd still get a fatal error and it would allow people who want to work with exceptions to take advantage of them. However, as stated the fact that PHP is inconsistent with its error levels would probably limit the usefulness of such a change because it'd probably lead to quite a few inconsistency. I think the people here who argue that exceptions suck are quite wrong. In most cases, you expect your code to work perfectly. If it doesn't, I don't think you usually want it to continue its regular control flow. Rather, it'd be easier to catch the exception and give some kind of useful error message. Exceptions allow you to get rid of all of those if() statements that check function return values (due to it being a headache many developers leave those out) and to handle errors in a centralized place for logging and outputting a nice error screen. After all they should be used for real errors and not for control-flow. I think people who argue that exceptions suck probably aren't the people who check every return code of their functions or they'd be completely pissed off with that error model. 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 to about exceptions plans to use them for just about every kind of error condition, and they expect them to be useful as such. I suspect this is because it is possible to differentiate between error type, and even severity, just through the class of the exception. Perhaps some kind of non-fatal exception equivalent could be worked out for 5.1/5.2? if continue or return was extended to allow returning from a catch to the point of execution after the throw statement, this would of course open a can of worms, but it might solve the issue. Obviously this would have to fail for any internal throw(), and be possible for user-level throw() only. Alternatively, it could return to the first user-level statement following the internal throw(). Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and 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
> }
> } catch {
> // handle exception
> }
>
>It's really crazy to need to mix both types of error handling within
>the same block of code.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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?" And thought, "only the devil would want to use exceptions as reflection." For everyone's sake, please don't allow such a usage or our scripts will be miles long. Thank-you. xo boots __ Do you Yahoo!? Yahoo! Tax Center - File online by April 15th http://taxes.yahoo.com/filing.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 agree. One programmer's E_NOTICE is an another's E_ERROR. However, right now, all non-fatal errors are essentially trapped (or ignored) the same way. [snip discussion on the merit of exceptions] > Personally, I am not sure what my take on this is as I think most of us > agree that it's a mess and there's no perfect solution. In an ideal world, > I would prefer to write DB connection/query/disconnection code without > having to check their return values, and if an error occurs, catch that > exception and give a meaningful error message. However, it seems that > finding the right solution for PHP is going to be pretty hard. I think the other problem is that we cannot come to a general consensus on the appropriate application of exceptions. There are some developers who would prefer they're *never* used. There are others who want to use them *always*. This isn't good. :) Until we can forge some middleground on *why* we should use exceptions, it's hard to come up with a solution for how we should go about solving the messy real world issues of legacy code, different error levels for similiar problems, etc, etc. Currently, as I see it, exceptions are maybe useful for application-level problems, but not for lower level errors. Essentially, you can use exceptions to handle errors in your own components, but not in any of the underlying extensions. Maybe this is how we want people to use exceptions in PHP, but I'd prefer this to be an overt decision instead of a side-effect of inconsistent extension deployment. > Thinking out loud, it might be interesting to think of some automatic > wrapping API, which could be used in order to use exception based PHP vs. > regular PHP. However, doing this in a way which is accurate and automatic, > especially as relying on our current E_* doesn't seem to be a good option, > would be quite hard. There are no excellent options here, but maybe we can come up with one that is good enough. -adam -- [EMAIL PROTECTED] author of o'reilly's php cookbook avoid the holiday rush, buy your copy today! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 recovered from) to exceptions, functionally this would not be very problematic because for people not using exceptions they'd still get a fatal error and it would allow people who want to work with exceptions to take advantage of them. However, as stated the fact that PHP is inconsistent with its error levels would probably limit the usefulness of such a change because it'd probably lead to quite a few inconsistency. I think the people here who argue that exceptions suck are quite wrong. In most cases, you expect your code to work perfectly. If it doesn't, I don't think you usually want it to continue its regular control flow. Rather, it'd be easier to catch the exception and give some kind of useful error message. Exceptions allow you to get rid of all of those if() statements that check function return values (due to it being a headache many developers leave those out) and to handle errors in a centralized place for logging and outputting a nice error screen. After all they should be used for real errors and not for control-flow. I think people who argue that exceptions suck probably aren't the people who check every return code of their functions or they'd be completely pissed off with that error model. Personally, I am not sure what my take on this is as I think most of us agree that it's a mess and there's no perfect solution. In an ideal world, I would prefer to write DB connection/query/disconnection code without having to check their return values, and if an error occurs, catch that exception and give a meaningful error message. However, it seems that finding the right solution for PHP is going to be pretty hard. Thinking out loud, it might be interesting to think of some automatic wrapping API, which could be used in order to use exception based PHP vs. regular PHP. However, doing this in a way which is accurate and automatic, especially as relying on our current E_* doesn't seem to be a good option, would be quite hard. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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, and a newer library. They develop there code, the option exists, and then someone with an older version of the library doesn't have that. Whether or not i have 4 spaces or 2 in my output is rather inconsequential. Now you deploy somewhere else and this explodes somewhere within a function and bumps the script out of a critical execution context and refuses to work. Setting an option has semantic meaning. Whitespace has no semantic meaning in PHP. These are apples and oranges. Rewind to the beginning of the discussion, the scope is not as broad as you claim. I did. fast-forward to the end of this message, that's exactly the point john brought up. He's talking about all E_WARNINGs in an OO context, not in an OO extension. I could, I could also catch my exceptions. There are plenty of other exceptions (casting errors, etc) that will irk me whenever I use Python. I've probably written a considerably large amount of python and I haven't run into this rampant exception problem you talk about. Could also be the reason why I like Python more than you... ;) It makes sense that overloads would cause exceptions, as it does with type casting exceptions - remember, python is a strongly typed language, that type schiznizzle is important to them. I'm not arguing whether it's important to them. I'm arguing that things that are not important to my app generate exceptions in Python. Something can be important in a language but not important to my app. Either i'm missing the point or we are agreeing this shouldn't be so. You were saying that not doing this was consistent with other languages. I was saying that it was not. Ok, then we disagree. I think its entirely inconsistent because the two systems don't map to each other, and you get plenty of cases where the two simply don't map. John is talking about *all* E_WARNINGs in OO code, and in the procedural variants, sending E_WARNINGs. The scope of E_WARNING is not in my opinion the same scope as an exception in any language, and we may just have to agree to disagree. The not-mapping issue is a serious one. PHP's procedural error-handling does not map well to Java or Python. PHP's OO error-handling can. The former can't change, the latter can. I don't think there's a clean answer. And before I incur a rant from Sascha about how I ramble endlessly without point, I'll resign from this argument. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 exception.
This is not by any stretch of the imagination an unrecoverable
error, but rather a simple failure. Yet, if you use tidy in a
script, and it is not within a try {} catch {} block your script
execution will be terminated because the configuration option could
not be resolved. This is much less than desirable and probably
confusing for someone who doesn't understand what an exception or
why he should care.
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?
I assume they don't want their script to stop executing, their
transactions to be rolled back and a nasty error page shown :
"Uncaught exception, could not set tabsize to 2 spaces"
That could just be my crazy assumption though.
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, and a newer library. They
develop there code, the option exists, and then someone with an older
version of the library doesn't have that. Whether or not i have 4
spaces or 2 in my output is rather inconsequential. Now you deploy
somewhere else and this explodes somewhere within a function and bumps
the script out of a critical execution context and refuses to work.
You might argue that python or java would throw an exception in
this case. For the majority of the java standard library and
python code i have found this the opposite, however, even conceding
that, PHP should never do this. We have the concept of warnings,
in our world an error of this type does *not* terminate script
execution. There are even less severe usages of warnings
throughout the PHP source code, and there is no reason to convert
them to exceptions. And if you don't, you still have the same
inconsistencies.
The discussion was on OO code throwing exceptions. Given that there
is very little OO core code in php4, I don't see a widespread
conversion happening.
No, this discussion was on having exceptions thrown instead of
E_WARNINGs inside OO code.
Rewind to the beginning of the discussion, the scope is not as broad
as you claim.
I did. fast-forward to the end of this message, that's exactly the
point john brought up.
The key point that you're missing in all this is that _you_ don't
know what's a serious error and what's not. Only the developer
knows. For instance, the python smtplib can throw any number of
exceptions based on bad connect data or bad command responses. Is
this a 'serious' error? It depends. If sending a mail is an
inconsequential part of the app, maybe it's just an informational
warning. It's also easy to imagine it being a very critical,
non-recoverable error. The severity of the error lies entirely in
the purview of the receiver.
Nothing sums this up for me better than KeyError, which is almost
never fatal in my applications but which constantly bites me in the
ass. Obviously your experiences may differ, which is really the
whole point.
Well, you can use get() now and be happy. :)
I could, I could also catch my exceptions. There are plenty of other
exceptions (casting errors, etc) that will irk me whenever I use
Python.
I've probably written a considerably large amount of python and I
haven't run into this rampant exception problem you talk about. Could
also be the reason why I like Python more than you... ;) It makes
sense that overloads would cause exceptions, as it does with type
casting exceptions - remember, python is a strongly typed language,
that type schiznizzle is important to them.
I'm not saying that exceptions should never be used. But, John
suggested "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'm undecided on whether it's advisable to throw E_WARNINGs as
exceptions. I think that all but engine-consistency-affecting
E_ERRORs should be exceptions, but that's a different discussion.
I would probably agree with you on E_ERRORs.
Either i'm missing the point or we are agreeing this shouldn't be so.
You were saying that not doing this was consistent with other
languages. I was saying that it was not.
Ok, then we disagree. I think its entirely inconsistent because the
two systems don't map to each other, and you get plenty
Re: [PHP-DEV] Exceptions and Errors
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 unrecoverable
error, but rather a simple failure. Yet, if you use tidy in a
script, and it is not within a try {} catch {} block your script
execution will be terminated because the configuration option could
not be resolved. This is much less than desirable and probably
confusing for someone who doesn't understand what an exception or
why he should care.
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?
I assume they don't want their script to stop executing, their
transactions to be rolled back and a nasty error page shown :
"Uncaught exception, could not set tabsize to 2 spaces"
That could just be my crazy assumption though.
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.
You might argue that python or java would throw an exception in this
case. For the majority of the java standard library and python code
i have found this the opposite, however, even conceding that, PHP
should never do this. We have the concept of warnings, in our world
an error of this type does *not* terminate script execution. There
are even less severe usages of warnings throughout the PHP source
code, and there is no reason to convert them to exceptions. And if
you don't, you still have the same inconsistencies.
The discussion was on OO code throwing exceptions. Given that there
is very little OO core code in php4, I don't see a widespread
conversion happening.
No, this discussion was on having exceptions thrown instead of
E_WARNINGs inside OO code.
Rewind to the beginning of the discussion, the scope is not as broad as
you claim.
I'm pointing out that the two paradigms don't map, and in other
languages for many of the common errors given by E_WARNINGs (but not
all) simply wouldn't propagate as Exceptions. Many cases it would,
but in order for this idea to work, it needs to map for the most part,
which it doesn't.
[snip]
You'll have a hard time defending Python as being restrained in it's
use of exceptions for warnings. It's a rather exception-happy
langugae and throws exceptions for the equivalent of most PHP
E_NOTICEs.
I haven't noticed that, and I've written quite a bit python code. It
does throw exceptions, no argument, but it depends largely on what you
are doing. The above example you've given is a place where an
exception is not out of place (although I don't particularly like one
being thrown), because you are using an overload. Different paradigm
than PHP arrays imho.
Most of the exceptions i've found when using both these languages
happen on something that maps to something more severe than a
configuration option not being found. YMMV.
The key point that you're missing in all this is that _you_ don't
know what's a serious error and what's not. Only the developer
knows. For instance, the python smtplib can throw any number of
exceptions based on bad connect data or bad command responses. Is
this a 'serious' error? It depends. If sending a mail is an
inconsequential part of the app, maybe it's just an informational
warning. It's also easy to imagine it being a very critical,
non-recoverable error. The severity of the error lies entirely in
the purview of the receiver.
Nothing sums this up for me better than KeyError, which is almost
never fatal in my applications but which constantly bites me in the
ass. Obviously your experiences may differ, which is really the
whole point.
Well, you can use get() now and be happy. :)
I could, I could also catch my exceptions. There are plenty of other
exceptions (casting errors, etc) that will irk me whenever I use
Python.
I'm not saying that exceptions should never be used. But, John
suggested "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'm undecided on whether it's advisable to throw E_WARNINGs as
exceptions. I think that all but engine-consistency-affecting E_ERRORs
should be exceptions, but that's a different discussion.
Either i'm missing the point or we are agreeing this shouldn't be so.
You were saying that not doing this was consistent with other
languages. I was saying that it was not.
George
--
PHP Internals - PHP Runtime Development Mailing List
To unsubsc
Re: [PHP-DEV] Exceptions and Errors
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. Yet, if you use tidy in a script, and it is
not within a try {} catch {} block your script execution will be
terminated because the configuration option could not be resolved.
This is much less than desirable and probably confusing for someone
who doesn't understand what an exception or why he should care.
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?
I assume they don't want their script to stop executing, their
transactions to be rolled back and a nasty error page shown :
"Uncaught exception, could not set tabsize to 2 spaces"
That could just be my crazy assumption though.
You might argue that python or java would throw an exception in this
case. For the majority of the java standard library and python code
i have found this the opposite, however, even conceding that, PHP
should never do this. We have the concept of warnings, in our world
an error of this type does *not* terminate script execution. There
are even less severe usages of warnings throughout the PHP source
code, and there is no reason to convert them to exceptions. And if
you don't, you still have the same inconsistencies.
The discussion was on OO code throwing exceptions. Given that there
is very little OO core code in php4, I don't see a widespread
conversion happening.
No, this discussion was on having exceptions thrown instead of
E_WARNINGs inside OO code. I'm pointing out that the two paradigms
don't map, and in other languages for many of the common errors given
by E_WARNINGs (but not all) simply wouldn't propagate as Exceptions.
Many cases it would, but in order for this idea to work, it needs to
map for the most part, which it doesn't.
Java and Python both use a mix of philosophies, and indeed there is
no complete consensus. However, in my experience and the books that
I've read on the subject, the general thought is:
a) throw specific exceptions, not just a "tidy_exception." PHP would
need to add a library of built-in exceptions to make this even
remotely useful. this is not feasible to do at RC1.6667
But the beauty of OO Code is that all the tidy exceptions should
derive from TidyException. So life can continue as before, with no BC
break.
b) don't throw exceptions except when truly exceptional. a function
failing is usually not an exception, but rather signified by failure.
The exception to this is when using constructors that contain logic
(considered bad practice by many btw), and overloading. In these
cases exceptions are used in leu of a better solution. This brings
us back to KeyError - KeyError is only thrown when overloading is
used:
names = ["barney", "fred", "wilma"]
print names["betty"] # throws an exception
print names.get("betty") # returns None
You'll have a hard time defending Python as being restrained in it's
use of exceptions for warnings. It's a rather exception-happy
langugae and throws exceptions for the equivalent of most PHP
E_NOTICEs.
I haven't noticed that, and I've written quite a bit python code. It
does throw exceptions, no argument, but it depends largely on what you
are doing. The above example you've given is a place where an
exception is not out of place (although I don't particularly like one
being thrown), because you are using an overload. Different paradigm
than PHP arrays imho.
Most of the exceptions i've found when using both these languages
happen on something that maps to something more severe than a
configuration option not being found. YMMV.
The key point that you're missing in all this is that _you_ don't know
what's a serious error and what's not. Only the developer knows. For
instance, the python smtplib can throw any number of exceptions based
on bad connect data or bad command responses. Is this a 'serious'
error? It depends. If sending a mail is an inconsequential part of
the app, maybe it's just an informational warning. It's also easy to
imagine it being a very critical, non-recoverable error. The severity
of the error lies entirely in the purview of the receiver.
Nothing sums this up for me better than KeyError, which is almost
never fatal in my applications but which constantly bites me in the
ass. Obviously your experiences may differ, which is really the whole
point.
Well, you can use get() now and be happy. :)
I'm not saying that exceptions should never be used. But, John
suggested "As a matter of consistency, I would like to suggest that for
those extensions which have a OO/proc
Re: [PHP-DEV] Exceptions and Errors
>
> 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 otherwise the script will terminate.
>>> Having
>>> to wrap some methods inside exceptions can be extremely frustrating
>>> since you
>>> may want to allow those methods to fail.
>>
>> Yes. This sucks. Maybe PHP should only issue exceptions for problems
>> of E_WARNING severity. An exception is an "Exceptional Event." If you
>> have an E_NOTICE or E_STRICT then that's an informational event, not a
>> exceptional one.
>
> I'm fine with this, but it's really just a documentation problem,
> right? Your method can still fail, you just need to try/catch around
> it.
>
> try {
>$obj->bornToFail();
> }
> catch(Exception $e){}
>
> Uglier than just swallowing a warning for sure, but still just a doc
> problem.
Might there be a possibility that an exception inside a "@ context" could
be ignored, too (that might also work with active custom error handlers,
I guess)?
Cheers,
Michael
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 no expectation that such things would be changed. We may keep in mind that a specific (or rare) situations now will certainly be a not so rare situation in a near future. When PHP5 is out and people start to create php5 only extensions (thinking that the internal API will then really be freezed). That's why this discussion is happening now. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 changed. We may keep in mind that a specific (or rare) situations now will certainly be a not so rare situation in a near future. When PHP5 is out and people start to create php5 only extensions (thinking that the internal API will then really be freezed). pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 like Java are used explicitly to catch fatal
errors, not to catch basic errors.
If 'languages like Java' means languages designed for OO, then this
is not true. Python throws exceptions for almost everything
(KeyError, for example). Even Java throws exceptions
(java.sql.Exception) for things like failed database connections
which are warnings in PHP.
Languages like Java doesn't mean languages designed for OO, but
languages closely adhering to the OO model that PHP uses, Java being
the language that can most easily be called the parent of our current
model - although I do keep Python in this context even after your
KeyError example. The triviality of an exception doesn't make
exceptions themselves less severe. Whether or not a KeyError is
warranted as an E_ERROR, doesn't in fact change that a KeyError will
bump you firmly out of your control flow branch, and make you handle
an error condition. In PHP, E_WARNINGs may be misused (that's a
discussion for another time, i think); but the fact remains, they do
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 inconsistencies.
A KeyError is an E_NOTICE in PHP. It's so frequent in loosely typed
languages that it is rarely severe. Your argument is a tautology: the
only reason it breaks control-flow in Python is because it's defined
to break control-flow there by means of it being an exception.
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. Yet, if you use tidy in a script, and it is
not within a try {} catch {} block your script execution will be
terminated because the configuration option could not be resolved.
This is much less than desirable and probably confusing for someone
who doesn't understand what an exception or why he should care.
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?
You might argue that python or java would throw an exception in this
case. For the majority of the java standard library and python code i
have found this the opposite, however, even conceding that, PHP should
never do this. We have the concept of warnings, in our world an error
of this type does *not* terminate script execution. There are even
less severe usages of warnings throughout the PHP source code, and
there is no reason to convert them to exceptions. And if you don't,
you still have the same inconsistencies.
The discussion was on OO code throwing exceptions. Given that there is
very little OO core code in php4, I don't see a widespread conversion
happening.
Java and Python both use a mix of philosophies, and indeed there is no
complete consensus. However, in my experience and the books that I've
read on the subject, the general thought is:
a) throw specific exceptions, not just a "tidy_exception." PHP would
need to add a library of built-in exceptions to make this even
remotely useful. this is not feasible to do at RC1.6667
But the beauty of OO Code is that all the tidy exceptions should derive
from TidyException. So life can continue as before, with no BC break.
b) don't throw exceptions except when truly exceptional. a function
failing is usually not an exception, but rather signified by failure.
The exception to this is when using constructors that contain logic
(considered bad practice by many btw), and overloading. In these
cases exceptions are used in leu of a better solution. This brings us
back to KeyError - KeyError is only thrown when overloading is used:
names = ["barney", "fred", "wilma"]
print names["betty"] # throws an exception
print names.get("betty") # returns None
You'll have a hard time defending Python as being restrained in it's
use of exceptions for warnings. It's a rather exception-happy langugae
and throws exceptions for the equivalent of most PHP E_NOTICEs.
Most of the exceptions i've found when using both these languages
happen on something that maps to something more severe than a
configuration option not being found. YMMV.
The key point that you're missing in all this is that _you_ don't know
what's a serious error and what's not. Only the develop
Re: [PHP-DEV] Exceptions and Errors
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 inconsistencies.
There is no BC break here. We are talking about specifically new
extensions written against ZE2 which have error conditions that should
be recoverable -- and *only* in the object context. Since most of PHP
does not provide a object context, there is no expectation that they
should be modified for exceptions.
> 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. Yet, if you use tidy in a script, and it is not within
> a try {} catch {} block your script execution will be terminated
> because the configuration option could not be resolved. This is much
> less than desirable and probably confusing for someone who doesn't
> understand what an exception or why he should care.
You have pulled one edge case out of an entire API, and the problem here
is probably that you shouldn't complain about setting an invalid
configuration option at all -- perhaps as a E_NOTICE. Furthermore, this
exception will only occur if you use $a = new tidy() instead of $a =
tidy_parse_file().
> You might argue that python or java would throw an exception in this
> case. For the majority of the java standard library and python code i
> have found this the opposite, however, even conceding that, PHP should
> never do this. We have the concept of warnings, in our world an error
> of this type does *not* terminate script execution. There are even
> less severe usages of warnings throughout the PHP source code, and
> there is no reason to convert them to exceptions. And if you don't,
> you still have the same inconsistencies.
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 changed.
> a) throw specific exceptions, not just a "tidy_exception." PHP would
> need to add a library of built-in exceptions to make this even remotely
> useful. this is not feasible to do at RC1.6667
Agreed. You can't do this in the time allowed. However, you can make
things throw tidy_exception and then in PHP 5.1 throw
tidySomeOtherMoreSpecificException which extends tidy_exception.
> b) don't throw exceptions except when truly exceptional. a function
> failing is usually not an exception, but rather signified by failure.
> The exception to this is when using constructors that contain logic
> (considered bad practice by many btw), and overloading. In these cases
> exceptions are used in leu of a better solution. This brings us back
> to KeyError - KeyError is only thrown when overloading is used:
If you're argument is that there should be some sort of consistency on
when an error is really an exception, I can't agree more.. However, that
it itself is an admission that there is a place for Exceptions in
internal PHP 5 OO which is not being addressed.
> Most of the exceptions i've found when using both these languages
> happen on something that maps to something more severe than a
> configuration option not being found. YMMV.
Its a two-line change that I'm willing to make -- I'm more concerned
about the other extensions which are not using exceptions at all,
especially when they are warranted.
John
--
-=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=-
John Coggeshall http://www.coggeshall.org/
The PHP Developer's Handbookhttp://www.php-handbook.com/
-=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=-
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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
> >stupid try..except block around it.
> If it's used only in object context.
And why OO codes should be overbloated with exceptions for non fatal
errors? I do not talk about fatal userland errors but fatal php
erros. But I may be a too old fashion programmer, where exceptions
were used to avoid crash, ugly exit and but not control flow.
I feel these exceptions issues more like the other "OO fanatic"
discussions. It will fall in many annoyed things in our codes,
depending about how the maintainers use exceptions. For instance
(I took tidy codes, no offence for the authors, I like tidy, but
not its exceptions usage):
if (tidyOptIsReadOnly(opt)) {
TIDY_THROW("Attempt to set read-only option '%s'", optname);
return FAILURE;
}
Ah? Sounds more like a notice to me. This kills the KISS.
My nightmare (shows the E_ERROR/E_WARNING issues explained in other
posts):
./sapi/cli/php -n -r 'tidy_parse_file("foo");echo "bar";'
The worst is:
tidy_get_opt (internal function name) which raises an exception if
the option does not exist. What a nightmare if I have to try{}catch
every piece of codes because the KISS'ed value/false principle is
droped in the name of OO.
So yes, a little HOWTO for the usage of exceptions should be nice,
both for internals and userland. But if the goals is to follow these
examples, then I ask to add an ini option: use_crappy_exceptions
On|Off
my little 2cts on this topic,
pierre
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and 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 with > a registered error handler, it has to be completely rewritten. If you're expecting this code to work in both PHP 4 and PHP 5, you're not using the OO extension interface, so no exceptions will be thrown. Things will work just like before. I also presume that exceptions are not handled by a registed error handler. That would be madness. :) I think by now I am resigned to the situation that PHP's internal error reporting system doesn't doesn't map well to exception handling. This problem is at least somewhat related to inconsistent application of E_WARNINGs, E_ERRORs, etc. Certain extensions (SOAP, Ming) love to throw E_ERRORs. Others won't throw an E_ERROR in even the worst of circumstances. Therefore, sometimes E_WARNINGs are harmless and other times they're fatal. Oh well. -adam -- [EMAIL PROTECTED] author of o'reilly's php cookbook avoid the holiday rush, buy your copy today! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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, not to catch basic errors.
If 'languages like Java' means languages designed for OO, then this is
not true. Python throws exceptions for almost everything (KeyError,
for example). Even Java throws exceptions (java.sql.Exception) for
things like failed database connections which are warnings in PHP.
Languages like Java doesn't mean languages designed for OO, but
languages closely adhering to the OO model that PHP uses, Java being
the language that can most easily be called the parent of our current
model - although I do keep Python in this context even after your
KeyError example. The triviality of an exception doesn't make
exceptions themselves less severe. Whether or not a KeyError is
warranted as an E_ERROR, doesn't in fact change that a KeyError will
bump you firmly out of your control flow branch, and make you handle an
error condition. In PHP, E_WARNINGs may be misused (that's a
discussion for another time, i think); but the fact remains, they do
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 inconsistencies.
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. Yet, if you use tidy in a script, and it is not within
a try {} catch {} block your script execution will be terminated
because the configuration option could not be resolved. This is much
less than desirable and probably confusing for someone who doesn't
understand what an exception or why he should care.
You might argue that python or java would throw an exception in this
case. For the majority of the java standard library and python code i
have found this the opposite, however, even conceding that, PHP should
never do this. We have the concept of warnings, in our world an error
of this type does *not* terminate script execution. There are even
less severe usages of warnings throughout the PHP source code, and
there is no reason to convert them to exceptions. And if you don't,
you still have the same inconsistencies.
Java and Python both use a mix of philosophies, and indeed there is no
complete consensus. However, in my experience and the books that I've
read on the subject, the general thought is:
a) throw specific exceptions, not just a "tidy_exception." PHP would
need to add a library of built-in exceptions to make this even remotely
useful. this is not feasible to do at RC1.6667
b) don't throw exceptions except when truly exceptional. a function
failing is usually not an exception, but rather signified by failure.
The exception to this is when using constructors that contain logic
(considered bad practice by many btw), and overloading. In these cases
exceptions are used in leu of a better solution. This brings us back
to KeyError - KeyError is only thrown when overloading is used:
names = ["barney", "fred", "wilma"]
print names["betty"] # throws an exception
print names.get("betty") # returns None
Most of the exceptions i've found when using both these languages
happen on something that maps to something more severe than a
configuration option not being found. YMMV.
-Sterling
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and 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 unrecoverable error. Exceptions enable the user (as in: the programmer as user of a certain API) to decide which conditions qualify as fatal and which do not. For example, an SQL parse error would be fatal in an app where the SQL is hardcoded, but would be a valid error condition in an app that allows user entry of SQL statements. Stating here which errors are fatal and which are not is therefore pointless. Being able to only handle the error conditions that you can reasonably expect, and ignore the others, is the whole purpose of providing exception handling in the first place. Having the whole PHP OO API return false for every error without giving the nature of the error defeats this purpose entirely. Therefore, IMO, proper implementation of exception handling should at least provide exception functionality for the entire OO API, and maybe even for the procedural API as well, as they're not interchangeable, meaning OO apps will use the procedural API as well. I'm well aware that this is not going to happen, so maybe a compromise would be possible. Perhaps a zval type IS_ERROR that evaluates to FALSE for most common purposes, but can be used to identify the actual error condition that occurred, or the ability to pass more context to a user-defined error handler could be considered ? And for the E_WARNINGs, maybe a built-in Exception specialization (ie. NonFatalException) that is ignored by the top level catch() ? -- Ard -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 rewritten.
Exceptions, by nature, can not be caught at the global level and then
modified, they are local. Of course, you could just surround your
global code with a try {} catch {} but that is just about the worst hack
I can imagine.
Unless there is a way to "resume" execution after the point of the error
(i.e. exactly how the current error handling works), exceptions will
only make things more exasperating. If I have to surround every single
method call with try {} catch {}, that = a bad design decision.
- say byebye to readability
- what if an extension upgrades and throws a new, more specific kind of
exception? instant code breakage, unless the catch-all is not paranoid
- EVERY try {} catch {} will need a catch-all, unless you're willing to
risk total breakage later.
- error handling is suddenly forced to be directly integrated with
program logic, and isn't that the opposite of exception handling's goals?
Greg
P.S.
This is what I mean by a "resume" statement:
function blah()
{
$a = $someobject->throwsexception();
$nextstatement = 'works?';
}
...
try {
blah();
} catch (Exception $e) {
log_exception($e);
if (thingsareok()) {
resume; // execution starts at "$nextstatement = 'works?';"
}
}
Without the ability to resume, we are forced to do
function blah()
{
try {
$a = $someobject->throwsexception();
} catch (Exception $e) {
$ok = pass_to_global_exception_handler_and_logger($e);
if (!$ok) {
throw ($e);
}
}
$nextstatement = 'ack';
}
for even the most minor of error conditions
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 capabilities of the language more difficult you will lose
those programmers to other languages. Consequently these programmers are
usually the ones responsible for large deployments of the language.
> So you're saying you write code like:
>
> // Don't care if this prints anything:
> $db = new SQLiteDatabase('foo.db');
> $r = $db->query($sql);
> foreach ($r as $row) {
> processRow($row);
> }
Almost ;-)
$r = $db->query($sql) or sql_error_handler($sql, $db);
It'll be the job of sql_error_handler() to determine what type of an error had
occurred and what action to take if any.
> FWIW, I just checked, and Java handles this dilemma in JDBC by *not*
> throwing exceptions upon SQL warnings. They still throw SQLExceptions
> for major DB errors.
Well, that would mean that you'll never be certain what may throw an
exceptions giving you a nasty mix of both that will confuse experienced and
inexperienced developers alike.
Ilia
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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' means languages designed for OO, then this is not true. Python throws exceptions for almost everything (KeyError, for example). Even Java throws exceptions (java.sql.Exception) for things like failed database connections which are warnings in PHP. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 by those extensions be thrown as Exceptions when called from > an OO syntax. I have already committed such a change to Tidy, and I > can't see any serious reason why such a change can't be implemented for > internal classes. > > Feedback welcome. 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. 2. KISS: PHP is supposed to be SIMPLE; with all thos advanced OO stuff writing scripts for PHP starts becoming less and less easy. Sure, they are already using OO but that's just a notation. Some extensions are only OO, like DOM, but that doesn't mean that every Joe Average has any idea on what exceptions are. Please, kepe things simple. Don't force people. Derick, The fact that you have something personal against OOP doesn't mean it's not good. 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 problem with OOP extensions throwing exceptions. 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. 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 unrecoverable error. Errors as exceptions are a different story. I don't think that's a bad idea at all. But leave good alone, warnings shouldn't be exceptions. -Sterling (*) Though my like is most definitely due to stockholm syndrome, and excessive brainrape. Nonetheless. :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 E_NOTICE/E_STRICT can be ignored.
Well, like I said, I'm against exceptions on E_NOTICE/E_STRICT. I
think there's some agreement on this point. Well, you, me, George, and
Derick. I add Derick because he's always against exceptions. :)
As to E_WARNINGs, what to do? Sometimes they can be safely ignored,
but it takes an experienced programmer to know those cases.
> > Your code cannot correctly retrieve those rows from the
> > database when you've ignored the error telling you that there was a
> > problem connecting to the database. :)
>
> You may not want to retrieve the rows in the 1st place.
So you're saying you write code like:
// Don't care if this prints anything:
$db = new SQLiteDatabase('foo.db');
$r = $db->query($sql);
foreach ($r as $row) {
processRow($row);
}
I think only two sets of programmers do this. Unfortunately, they're
at the spectrums. Newbies and gurus. Newbies because they don't know
any better and gurus because they know exactly what's going to happen.
I'm trying to get newbies to move into the middle range and I'm
ignoring the top 1% of developers. :)
> > Handling UNIQUEness queries is exactly the type of problem you're
> > going to need to trap. For example:
>
> Your example is not entirely correct. You'd first need to use
> $db->lastError() to the error code, $e->getCode() will return something else
> all together. However the bottom line is that now your exception handling
> mechanism is far more complex then it should/could be. If your block has a
> query() method with a query that can fail you'd need to add special
> conditions to handle it in the end you end up with an overly complex handling
> mechanism.
Right. Sorry about that. I had played around with trying to get SQLite to
throw exceptions and had placed the lastError() as the exception code.
> If you start putting an try {} catch {} block around every individual query
> method as an alternative, then you kill the whole point of exceptions, no?
FWIW, I just checked, and Java handles this dilemma in JDBC by *not*
throwing exceptions upon SQL warnings. They still throw SQLExceptions
for major DB errors.
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.
-adam
--
[EMAIL PROTECTED]
author of o'reilly's php cookbook
avoid the holiday rush, buy your copy today!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 should throw exceptions at all. If nothing should throw exceptions then they shouldn't be in the language. However, having decided to place exceptions to the language, it's only rational to implement them in a sane way. I understand you're against them. Personally, I may not use them. However, I really don't think it makes any sense to set exceptions up for failure with a half-baked implementation. (I'm not saying the ZE2 part of exeptions is half-baked. That works. It's the deployment of exceptions that's half-baked.) -adam -- [EMAIL PROTECTED] author of o'reilly's php cookbook avoid the holiday rush, buy your copy today! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 correctly retrieve those rows from the
> database when you've ignored the error telling you that there was a
> problem connecting to the database. :)
You may not want to retrieve the rows in the 1st place.
> Handling UNIQUEness queries is exactly the type of problem you're
> going to need to trap. For example:
Your example is not entirely correct. You'd first need to use
$db->lastError() to the error code, $e->getCode() will return something else
all together. However the bottom line is that now your exception handling
mechanism is far more complex then it should/could be. If your block has a
query() method with a query that can fail you'd need to add special
conditions to handle it in the end you end up with an overly complex handling
mechanism.
If you start putting an try {} catch {} block around every individual query
method as an alternative, then you kill the whole point of exceptions, no?
Ilia
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 otherwise the script will terminate.
Having
to wrap some methods inside exceptions can be extremely frustrating
since you
may want to allow those methods to fail.
Yes. This sucks. Maybe PHP should only issue exceptions for problems
of E_WARNING severity. An exception is an "Exceptional Event." If you
have an E_NOTICE or E_STRICT then that's an informational event, not a
exceptional one.
I'm fine with this, but it's really just a documentation problem,
right? Your method can still fail, you just need to try/catch around
it.
try {
$obj->bornToFail();
}
catch(Exception $e){}
Uglier than just swallowing a warning for sure, but still just a doc
problem.
Either that or uncaught exceptions should be E_WARNINGs instead of
E_ERRORs. (I don't want to introduce Java's checked versus unchecked
exception concept.)
-1.
George
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 inside exceptions can be extremely frustrating since you
> may want to allow those methods to fail.
Yes. This sucks. Maybe PHP should only issue exceptions for problems
of E_WARNING severity. An exception is an "Exceptional Event." If you
have an E_NOTICE or E_STRICT then that's an informational event, not a
exceptional one.
Either that or uncaught exceptions should be E_WARNINGs instead of
E_ERRORs. (I don't want to introduce Java's checked versus unchecked
exception concept.)
> For example the query method in SQLite can safely be allowed to fail
> in certain instances. In other instances when you care about
> failures there may be a need to implement custom handlers depending
> on the nature of the error. For example if a query fails due to a
> uniqness constrait, an UPDATE query would be ran while in all other
> instances an error would be logged etc...
Still, you shouldn't be ignoring E_WARNINGs unless you have a good
reason. Your code cannot correctly retrieve those rows from the
database when you've ignored the error telling you that there was a
problem connecting to the database. :)
Handling UNIQUEness queries is exactly the type of problem you're
going to need to trap. For example:
try {
$db = new SQLiteDatabase('foo.db');
$db->query('INSERT...');
} catch (SQLiteException $e) {
if ($e->getCode() == 19) {
// UNIQUEness violation
$db->query('UPDATE...');
} else {
// log error
error_log($e->getMessage() . ': ' . $e->getCode());
}
}
-adam
--
[EMAIL PROTECTED]
author of o'reilly's php cookbook
avoid the holiday rush, buy your copy today!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 problem with OOP extensions throwing exceptions. I agree. I don't think we should modify the functional context at all. However, uf bundled extensions don't throw exceptions (or even worse, some do and some don't) then why did we both implementing exceptions? 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. -adam -- [EMAIL PROTECTED] author of o'reilly's php cookbook avoid the holiday rush, buy your copy today! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 caught otherwise the script will terminate. Having to wrap some methods inside exceptions can be extremely frustrating since you may want to allow those methods to fail. For example the query method in SQLite can safely be allowed to fail in certain instances. In other instances when you care about failures there may be a need to implement custom handlers depending on the nature of the error. For example if a query fails due to a uniqness constrait, an UPDATE query would be ran while in all other instances an error would be logged etc... Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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 changes should be released as quickly as possible. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
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. As I said, OOP extension authors who prefer to throw exceptions can do so if they wish (such as ext/SOAP). I think it's important to keep the old error handling for the functional paradigm. I kind of like my idea of being able to specify exceptions or not in the constructor, but I don't think this is something which should be mandatory. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
