could PHP5 be an exceptional mess?
Published 2004-06-18 07:57:31
PEAR dev is hot with the exception fever at present, The OO purists are beating down the door requesting the eviction of that horible legacy of a bygone age, PEAR_Error. And hoisting the flag of the Exception god at the gates.
Well, It's not really that bad, but it made a fun read. But as Jeff Moore Points out, Exceptions in PHP5, will (and have now) open a whole new can of worms.
Probably like alot of people, with this on the horizon,I have been interested to see last years timely ramblings of Joel that exceptions are evil, not that I always agree with him, but his arguments are rarely too flawed. There followed a huge weblog back and forth about the Greatness and Disaster that Exceptions brought (all this without any reference to the earthquake about to occur in PHP).
I've generally suffered with exceptions, I've hacked on programs written in C#, Java and Python, and found that errors raised by Exceptions tended to be very cryptic, and confusing messages. Perhaps partly due the lack of context information, like line numbers, that is displayed by those languages. But probably Just as frequently by the horrific coding of
Ok - so you have your own exception class, but am I expected to guess what the authors abbreviations mean?
One of the beautys of PHP4 is that it allows you to do simple things simply, and complex things without the hastle. Without exceptions, It's very easy to let things fail, and not care about it. Ok, it's not perfect programming, but There are levels of failure that you really do not care about. PHP's often emits E_WARN on a variety of code (reading from unassigned variables etc.), that would not justify a Exception. Similarly, In PEAR, there are many situations where if something failed, It is not that critical.. (like updating a database row, but there is no new data applied).
I do ponder sometimes what would be the answer for Exceptions, is throw always the way to go?
Realistically, PEAR classes should probably impliment their own exceptions (eg. Log_Exception), the theory always was that, Packages where supposed to implement their own _Error class, that included usefull things like translations of error messages..
Just returning exceptions, rather than throwing them, at least goes some way towards making them more usefull, although it would be better if PHP core could check if an Exception was returned, within a try {} catch () {} block, that catch was actually called..
Well, It's not really that bad, but it made a fun read. But as Jeff Moore Points out, Exceptions in PHP5, will (and have now) open a whole new can of worms.
Probably like alot of people, with this on the horizon,I have been interested to see last years timely ramblings of Joel that exceptions are evil, not that I always agree with him, but his arguments are rarely too flawed. There followed a huge weblog back and forth about the Greatness and Disaster that Exceptions brought (all this without any reference to the earthquake about to occur in PHP).
I've generally suffered with exceptions, I've hacked on programs written in C#, Java and Python, and found that errors raised by Exceptions tended to be very cryptic, and confusing messages. Perhaps partly due the lack of context information, like line numbers, that is displayed by those languages. But probably Just as frequently by the horrific coding of
throw new MyWgtException()
Ok - so you have your own exception class, but am I expected to guess what the authors abbreviations mean?
One of the beautys of PHP4 is that it allows you to do simple things simply, and complex things without the hastle. Without exceptions, It's very easy to let things fail, and not care about it. Ok, it's not perfect programming, but There are levels of failure that you really do not care about. PHP's often emits E_WARN on a variety of code (reading from unassigned variables etc.), that would not justify a Exception. Similarly, In PEAR, there are many situations where if something failed, It is not that critical.. (like updating a database row, but there is no new data applied).
I do ponder sometimes what would be the answer for Exceptions, is throw always the way to go?
function myblobby() {
return new Exception("There was a problem with myblobby()");
}
function myblobbyDie() {Could that be made to throw an Exception, even though the myblobby call is not normally fatal? could this be done? - without the intervention of PHP core?, possibly?
throw new Exception("There was a problem with myblobby()");
}
$object->myblobby()->doSomething();
class Log_Exception extends Exception {
function __call() {
throw $this;
}
function __get() {
throw $this;
}
function __set() {
throw $this;
}
}
Realistically, PEAR classes should probably impliment their own exceptions (eg. Log_Exception), the theory always was that, Packages where supposed to implement their own _Error class, that included usefull things like translations of error messages..
Just returning exceptions, rather than throwing them, at least goes some way towards making them more usefull, although it would be better if PHP core could check if an Exception was returned, within a try {} catch () {} block, that catch was actually called..
Mentioned By:
google.com : april (84 referals)
google.com : december (73 referals)
google.com : php catch warning (48 referals)
google.com : php5 debugger (41 referals)
www.procata.com : Jeff Moore's Blog » Exceptional PHP (23 referals)
google.com : php5 stack trace (17 referals)
google.com : php try catch warning (12 referals)
google.com : php5 __set (10 referals)
google.com : php stacktrace (9 referals)
google.com : php5 debug (9 referals)
google.com : php5 catch warning (8 referals)
google.com : Kannan Goundan (7 referals)
google.com : php catch warning messages (7 referals)
google.com : PHP5 try catch warning (6 referals)
www.cavorite.com : cavorite.com | blog | Breves y tacaas (5 referals)
google.com : catch warning php (5 referals)
google.com : php "catch warning" (5 referals)
google.com : php print stack trace (5 referals)
google.com : PHP try catch warnings (5 referals)
google.com : catch warning php5 (4 referals)
google.com : april (84 referals)
google.com : december (73 referals)
google.com : php catch warning (48 referals)
google.com : php5 debugger (41 referals)
www.procata.com : Jeff Moore's Blog » Exceptional PHP (23 referals)
google.com : php5 stack trace (17 referals)
google.com : php try catch warning (12 referals)
google.com : php5 __set (10 referals)
google.com : php stacktrace (9 referals)
google.com : php5 debug (9 referals)
google.com : php5 catch warning (8 referals)
google.com : Kannan Goundan (7 referals)
google.com : php catch warning messages (7 referals)
google.com : PHP5 try catch warning (6 referals)
www.cavorite.com : cavorite.com | blog | Breves y tacaas (5 referals)
google.com : catch warning php (5 referals)
google.com : php "catch warning" (5 referals)
google.com : php print stack trace (5 referals)
google.com : PHP try catch warnings (5 referals)
google.com : catch warning php5 (4 referals)
Follow us
-
- Some thoughts on the language server and its usefulness in the roobuilder
- Roo Builder for Gtk4 moving forward
- Clustered Web Applications - Mysql and File replication
- GitLive - Branching - Merging
- PDO_DataObject Released
- PDO_DataObject is under way
- Mass email Marketing and anti-spam - some of the how-to..
- Hydra - Recruitment done right
Blog Latest
-
Twitter - @Roojs