I don't know, I think all of these are answers in search of a problem that's already been satisfactorily resolved with Zend::exception().
To be honest, I also don't understand what the problem is in the e-mail that touched off this subject. "Exceptions are thrown inside of Zend[_*] classes so it's a job of developers and contributors to keep Zend Framework away from bugs." It sounds like Aleksey misunderstands the purpose of exceptions in Zend Framework, as if they indicate that there are bugs in the framework itself instead of calling attention to things like incorrect usage. The code says 'throw Zend::exception()'. It's clear that it's a factory method throwing an exception. I do think there is room to consider alternate implementations, however, like Ralph suggested. Zend_Exception::factory(), for example, does seem more obvious. Here's an idea of convention over configuration. You could either have one exception class allotted to each top-level component, or an exception for every subdirectory. Then you can just call: throw Zend_Exception::factory($message, __CLASS__); The factory could parse the second parameter and return the appropriate exception automatically. -Matt > Various Alternatives (in no particular order) > ==================================== > Aggregate all these "one liners" into a single file, and dispense with > attempts to optimize the loading of these one liners. > > For "empty" exception classes, use a shared class, combined with a > user-defined exception code ( http://www.php.net/exceptions ). > > Ignore the perceived performance issue (might not be present / severe > when using various byte-code caching tools under real-world conditions), > and return to the original approach for handling exceptions in the ZF. > > There are several other possibilities, but do any provide the same > functionality without resorting to numerous files containing an empty > class definition? > > Cheers, > Gavin > > Ralph Schindler wrote: >> Yes, this is the case, the exception object will populate its internal >> members at construction time, and having been thrown makes no >> alterations to internal members. This is good b/c a trace at the time >> of construction will persist until/or when the developer wishes to >> handle it. >> >> I personally don't need line/file as much as exception type, so this >> has little affect on me. But to appease those that rely on file/line, >> why not add to methods to the Zend_Exception class (which extends >> exception and it is expected that all core exception classes derive >> from. >> >> class Zend_Exception extends Exception >> { >> ... >> final function getTraceLine($traceDepth = 1) { ... } >> final function getTraceFile($traceDepth = 1) { ... } >> } >> >> This will allow developers to lines and files from the trace, not the >> constructor. Bam, everyone happy ;) >> >> -ralph >> >> >> Bill Karwin wrote: >>> Okay I just tried this: >>> >>> <?php >>> function testException() >>> { >>> require_once 'Zend.php'; >>> try { >>> $x = Zend::exception('Zend_Exception', 'boo!'); >>> throw $x; >>> } catch (Zend_Exception $e) { >>> echo "{$e->getMessage()}\n"; >>> echo "file: {$e->getFile()}\n"; >>> echo "line: {$e->getLine()}\n"; >>> echo "trace: {$e->getTraceAsString()}\n"; >>> } >>> } >>> >>> testException(); >>> ?> >
