Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:4411 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 6645 invoked by uid 1010); 6 Sep 2003 16:02:03 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 6620 invoked by uid 1007); 6 Sep 2003 16:02:02 -0000 Message-ID: <20030906160202.6619.qmail@pb1.pair.com> To: internals@lists.php.net References: <1571295530546.20030905172421@post.rwth-aachen.de> <1571295530546.20030905172421@post.rwth-aachen.de> <5.1.0.14.2.20030906082904.036cf2d0@127.0.0.1> Date: Sat, 6 Sep 2003 13:02:03 -0300 Lines: 27 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Posted-By: 200.196.104.198 Subject: Re: [PHP-DEV] Default exception handler From: cunha17@uol.com.br ("Cristiano Duarte") Hi Andi, IMHO I think there should be a way to catch all kinds of exceptions whether they inherits from "Exception" or not. It's specially important in standalone applications like those in PHP-GTK. An external library can throw an unkown exception an it could terminate the program abnormally. Instead, if we can catch this (at the moment) "unknown exception", maybe it would be possible to recover the program stability. Cristiano Duarte "Andi Gutmans" escreveu na mensagem news:5.1.0.14.2.20030906082904.036cf2d0@127.0.0.1... > Hi Marcus, > > I implemented this functionality about a year ago (if I'm not mistaken it > was part of the original ZE2 tree). > The reason we removed it (IIRC) was that we thought it would lead to > cleaner PHP code and would force only objects being thrown (although this > can be done in other ways). > I would like to keep things as-is because I think it's cleaner this way. > Give the developer the benefit of the tought that he can design his > Exception hierarchy in a good way, wether he inherits from our "Exception" > class or from his own exception class. > > Andi