At 08:12 AM 2/13/2004 -0500, Sterling Hughes wrote:
zeev Thu Feb 12 05:24:40 2004 EDT
Modified files:
/ZendEngine2 zend_default_classes.c zend_default_classes.h
zend_execute.h zend_execute_API.c
Log:
Exceptions updates:
- Enforce exceptions to be derived from class Exception. This allows
users to perform catch-all. It's not yet complete, so don't get
comfortable with it just yet :) Updates are coming soon.This is imho wrong. Exception is not a requirement, but an optional
thing. For the most part, all user exceptions should inherit from
"Exception," but that same onus is not on extension space exceptions, or
exceptions that are meant to be thrown out of bounds.Ie, you should be able to have:
try {
foo();
} catch (Exception $e) {
} catch (InternalException $ie) {
}What is the reasoning for this new change?
The reasoning is that it allows users to do a catch-all (which otherwise
we'd add to the language syntax). It also adds cleanliness to the Exception
hierarchy and allows PHP code to interact with PHP code which isn't written
by the developer knowing that there's a common interface (such as
getMessage()) which the exception always adheres to. That improves the
ability of exception handling especially debugging and logging significantly.
i.e.
try {
...// Main code which calls PEAR, SOAP, Smart, external stuff and
so on....
} catch (Exception $e) {
print "Damn something is really wrong here\n";
print $e->getMessage();
}
Andi
--
Zend Engine CVS Mailing List (http://cvs.php.net/)
The reasoning is that it allows users to do a catch-all (which otherwise
we'd add to the language syntax). It also adds cleanliness to the Exception
hierarchy and allows PHP code to interact with PHP code which isn't written
by the developer knowing that there's a common interface (such as
getMessage()) which the exception always adheres to. That improves the
ability of exception handling especially debugging and logging
significantly.
That second part is a Throwable interface, not a base class (and
Exception isn't even an ABC.)
i.e.
try {
...// Main code which calls PEAR, SOAP, Smart, external stuff and
so on....
} catch (Exception $e) {
print "Damn something is really wrong here\n";
print $e->getMessage();
}
I get the concept, that's the reason Exception was added. But its meant
to be a voluntary thing (I believe this has been discussed before btw),
a standard class that gives users something to build upon, should they
want to. I think an all-your-base-is-belonging-to-Exception is the
wrong way to go. If you really want a catch-all or some type of
consistency the way to go is either a Throwable interface (which makes
it more of a pain to write exceptions) or the generic:
catch ($e) {
}
syntax.
_Sterling
--
"Reductionists like to take things apart. The rest of us are
just trying to get it together."
- Larry Wall, Programming Perl, 3rd Edition
[...]
I get the concept, that's the reason Exception was added. But its meant
to be a voluntary thing (I believe this has been discussed before btw),
a standard class that gives users something to build upon, should they
want to. I think an all-your-base-is-belonging-to-Exception is the
wrong way to go.
I agree with Sterling. What if I have some really methods in my base
class that I rely on being existant in each and every subclass of it,
including Exception (or any other name I thought of to work around
"Exception" being built-in)?
- Timm