# [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_default_classes.c zend_default_classes.h zend_execute.h zend_execute_API.c

- Thread: https://externals.io/message/7812
- Original archive: https://news-web.php.net/php.internals/7812
- Started by Andi Gutmans on 2004-02-13T17:47:31+00:00
- Messages: 3
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #7812 — Andi Gutmans — 2004-02-13T17:47:31+00:00

URL: https://externals.io/message/7812#7812

At 08:12 AM 2/13/2004 -0500, Sterling Hughes wrote:
> > […]
>
>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/)

---

## #7815 — Sterling Hughes — 2004-02-13T17:54:29+00:00

URL: https://externals.io/message/7812#7815 · In reply to: #7812

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

---

## #7830 — Timm Friebe — 2004-02-15T10:04:43+00:00

URL: https://externals.io/message/7812#7830 · In reply to: #7815

[...]
> 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