Re: Re: PEAR_Warning proof of concept

Sergio Carvalho wrote:

Alan Knowles wrote:

I wonder if having the ability to elevate warnings to exceptions may be overdesigning the class.. - Trouble is that designing something as core as the error/warning handler, you are between a rock and and hard place (or whatever the phrase is). Your dammed if you add it in and dont need it, and your dammed if you dont, and you have to break BC later.. :)

Can you please provide an example of a situation where a warning would be elevated to an exception? I can easily imagine the other way around: an Exception being downgraded into a Warning, upon incomplete error recovery. For a Warning to be upgraded to an Exception, the lower library must have been throwing warnings in place of exceptions, no?

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. Hans