Re: Re: PEAR_Warning proof of concept

From: Date: Mon, 12 Jul 2004 00:45:17 +0000
Subject: Re: Re: PEAR_Warning proof of concept
References: 1 2 3 4 5  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-31866@lists.php.net to get a copy of this message
Hans Lellelid wrote:
Here's an example from JDBC also: DataTruncation: "An exception that reports a DataTruncation warning (on reads) or throws a DataTruncation exception (on writes) when JDBC unexpectedly truncates a data value." I can definitely see cases whare an underlying warnings may need to be re-cast as an exception and equally easily see cases where exceptions get swallowed and turned into warnings for logging purposes, etc. I think, therefore, that Greg's proposal of using a commonly derived class would make a *lot* of sense. I don't think warnings are going to be frequent enough to warrant real concern of the object cost. I think, however, that it would be great to keep the actual 'throw' stuff away from warnings & for that reason see the direct integration with the PEAR_Exception class as misplaced. Exceptions and warnings should not be confused because they have drastically different effects on code design, etc. IMHO it should, however, be possible to promote or demote them depending on calling context.
I agree. Exceptions and warnings are different. I have already wrote about that in the wiki, while commenting Greg's entries. The best system I imagine right now would be for PEAR Exceptions to be quite bare, and based off PHP Exceptions, while adding these properties: 1) Single hierarchy root. All exceptions descend from PEAR_Exception, so you can easily all errors at the top-level. 2) Support rewrapping, or exception nesting so we can disallow rethrowing of exceptions. 3) Work closely with PEAR_Warning (I don't know if this exists), for the common operations of demotion and promotion to/from warnings. 4) Provide a throwing/filtering method so it is possible to silence specific subclasses of PEAR_Exception. Namely, Exceptions don't have to support severity levels, or publisher/subscriber patterns. These sit rather well in a warning class. With this definition, it is possible to acomodate escalating warnings into exceptions or downgrading exceptions into warnings. I think it also acomodates other questions posed in the list, namely the ability to silence errors when in RAD mode. Cheers, Sérgio Carvalho

Attachment: [application/pgp-signature] OpenPGP digital signature signature.asc
« previous php.pear.dev (#31866) next »