Re: Error supressing in PHP5 [was PEAR_Interop... [was PEAR_Warning...]]
| From: | Justin Patrin | Date: | Tue, 13 Jul 2004 23:06:22 +0000 |
| Subject: | Re: Error supressing in PHP5 [was PEAR_Interop... [was PEAR_Warning...]] | ||
| References: | 1 2 3 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-31999@lists.php.net to get a copy of this message | ||
On Tue, 13 Jul 2004 23:56:40 +0100, Jon Wood <jellybob@gmail.com> wrote:
> On Tue, 13 Jul 2004 15:06:54 -0700, Justin Patrin <papercrane@gmail.com> wrote:
> >
> >
> > On Tue, 13 Jul 2004 22:51:36 +0100, Jon Wood <jellybob@gmail.com> wrote:
> > > I've never used set_exception_handler, but could a custom handler be
> > > developed (possibly along with PEAR_Exception) which would allow a
> > > list of exceptions to expect and ignore be developed, with anything
> > > that isn't expected being displayed?
> > >
> > > This would also work for non-PEAR packages, since it would simple be
> > > given the list of classes to expect, and would allow trees of
> > > exceptions to be ignored by defining their parent class
> > > (PEAR_Exception...) as one to ignore.
> > >
> >
> > Unless all of the refs I found from google are wrong (this isn't in
> > the docs yet...argh!), this function is only called when an exception
> > reaches the top level uncaught. This would mean that the stack has
> > already been unraveled, so this wouldn't work unless it:
> > 1) is run for *every* exception
> > 2) allows for stopping an exception form being thrown (ie, re-throw
> > the exception or return true if you want the exception to keep going)
> >
> Isn't the only ones that are a problem the ones that get to the top
> level without being caught anyway - if you've already caught an
> exception then you obviously aren't worried about it needing to be
> suppressed anyway.
>
True, but the call stack would already be unraveled, making it
impossible to continue. In addition, the idea was to make *all* of a
certain type of exception into warnings...which would bypass the catch
blocks.
I guess that could possibly screw up lower level error handling...hmmm...
>
>
> > This wouldn't really be the same function as the current
> > set_exception_handler(). If this did get implemented, I would suggest
> > that the current set_exception_handler() be renamed to
> > set_default_exception_handler() and the new function be
> > set_exception_handler().
> >
--
DB_DataObject_FormBuilder - The database at your fingertips
http://pear.php.net/package/DB_DataObject_FormBuilder
paperCrane --Justin Patrin--