Re: Fw: setStub inconsistencies - dubious patch attached

Steph Fox wrote: > Hi Greg, > >>>> To start with there are exceptions all the way through that method, >>>> which >>>> seems like a pretty bad idea given that it's supposed to return a >>>> Boolean >>>> value. Shouldn't there be a bog-standard E_WARNING on failure? And why >>>> would >>>> you want to throw an exception - which for most mortals causes a fatal >>>> error - just because you couldn't set the stub to anything other than >>>> default? Also, when you rely on exceptions, calling setStub() with the >>>> wrong >>>> data can result in a completely empty phar because there's no way to >>>> return >>>> FALSE. So I don't think exceptions work well there, given that this >>>> code is >>>> supposed to be easy for other people to use anyways. >> >> There are two ways of accessing phar archives: the stream wrapper and >> the Phar object. The stream wrapper has a context option for setting >> the stub, and any problems there cause E_WARNING to be raised. All >> problems with the OO interface use exceptions for error handling. The >> idea is that you encase your OO stuff in try/catch, or use the stream >> wrapper for simpler stuff. I don't want to change this behavior, it >> would mean rewriting all of the OO stuff, or having an inconsistency. > > I have a suggestion you may or may not like. Would it be possible to > have an INI_ALL directive to use exceptions or standard errors? I'd > personally have it with standard errors by default except in cases > where there would be a fatal error anyway, which basically restricts > exceptions-by-default to failures in the constructor. I don't think it > matters greatly that the internal code is OO... Point being, if you're > aiming for this to go into the PHP core, exceptions are literally the > exception and not the rule there. I am open to making this more flexible, but I'd prefer exceptions by default for the OO, and rather than use ini, allow per-process disabling via a static method, something like Phar::triggerErrors(), so that folks without access to ini can more easily control this. On an unrelated rant, I've always hated PHP's native error handling, it's never made debugging easier for me, and often made it much more painful. Exceptions, with their easily accessed backtrace and error origin localization are much more conducive to proper debugging, as about 1/3 of the time the error is actually triggered by a logic error 2 or 3 method calls up the chain. Having that backtrace makes all the difference. Additionally, the ability to re-package an error - or multiple errors - into another abstract container is very handy, and just much harder to do or impossible with trigger_error. Greg