The worries with the built-in PHP5 Exception class

at 2004-11-23 in PHP5 by friebe (0 comments)

PHP5 ships with a built-in exception class, called Exception. Now as this may seem as a nice feature in the beginning, it turns out to be a pain in the ass for our framework. Short version: Exception is not an Object. Long version follows.

In the PHP4 version of the XP framework (and early PHP5 alphas of it), the class lang.Throwable extends lang.Object (as any other class). This gives us a one-rooted class hierarchy just like in Java or C#.

Now, a while ago, just before PHP 5.0.0 was released, it was decided a built-in exception class would be a really good idea:

No one would have to implement it themselves
The Zend Engine could rely on this class having a certain functionality

I disagreed, saying that everybody could just implement their own exception class. C'mon - I said - it's not as if this was really tough. PEAR, for example, could just package one into their core distribution and everybody's happy. Maybe even having to implement an IException interface or whatever, so the engine could be sure the needed functionality is supported.

Whatsoever, people on the PHP developer's list thought this would make PHP too complex, would lead to everybody reinventing the weel and - remember - PHP is supposed to be easy to learn (right, just as if all the new OOP stuff is easy. Sure).

So, after this descision was made (and, I guess, it is irrevokable), this is what we had to do lang.Throawable to get the PHP5 version of the XP framework working again:

Let this class extend the built-in exception class, this is required in PHP5. This, of course, breaks the class hierarchy but there is unfortunately no workaround.

This requirement is idiotic and forces us to do the following:

Break inheritance.
Throwable is not an object. Thus, when using Object as a class type hint, you won`t be able to pass Throwables (or any other exceptions, because they all derive from Throwable). Possible
solution might be to add an interface to XP which both Object and Throwable implement.
Duplicate code from Object into Throwable. In detail, these are the methods hashCode(), equals(), getClassName(), getClass() and __toString() - the latter being a wrapper around the magic PHP function that simply calls toString().
Live with the fact that exception consume even more memory. This is due to the fact that trace is a private member in the built-in exception class and that we have our own stack trace in the protected _trace - we want subclasses to have access to it and we want to have it consist of StackTraceElements, not of an untyped array of mixed (which is the same as debug_backtrace() gives us).
Ignore the getTrace() and getTraceAsString() methods inherited from the built-in exception. They're public, so we can't prohibit users from calling them, but they really should be using getStackTrace() to get the stack trace. We can't override them as they are final.
Cannot have getMessage() documented in Throwable (or getCode(), getFile() or getLine() in other exception classes that may want to implement these) as all of them are final. Workaround: Choose different names (getFileName(), getLineNumber() as seen in xml.XMLFormatException).

As a reference, see the following discussion on the PHP developer's mailing list:

You can subscribe to the XP framework's news by using RSS syndication.

The worries with the built-in PHP5 Exception class

Subscribe

Categories

Related