What would be truly useful is to have generic get/set methods automatically created at compilation time, and any references to retrieving or setting values would always look for the appropriate getter or setter. Since they’d be automatically added at compile time, they’d always be there. For the times that you’d want to modify the behaviour, simply write a getter or setter with the customer behaviour and it would override (or obviate?) the default one that the PHP compiler would normally generate.

This would allow for much more succint code to be written – loads of boilerplate code would be avoided, and there’d be no need to have to refactor calls to properties to explicity use get/set methods – it’d be transparent. Less code, standardized behaviour, what’s not to love? (yeah yeah, some extra work at runtime – code caching would solve the bulk of that issue).

Jon, I think you completely missed the point of this article. Most exceptions (look at Zend Framework) don’t actually implement new functionality; they simply extend the existing exceptions so that you know which library threw the exception.

As for the getter and setter method, this is a tried-and-true programming strategy, and though you may disagree with it, that’s your choice. Lots of people choose to use it, and I’m one of those people; it’s not an inappropriate or incorrect way of doing things, just a different one from perhaps how you would do it.

You seem to be saying by not handling and rethrowing you *don’t* know where where the exception was raised. Surely the opposite is true? If you don’t handle and rethrow you know *exactly* where the original exception was raised without it being dressed up in layers of other exceptions that were triggered as the problem bubbles up through the layers.

You’ve also said “it is impossible for us to ensure that we have properly abstracted our application” which I’m not sure I understand.

It’s unecessary overhead. If you want to go this route, why not just make the variable public and define it whenever you want, wherever you want. Defining a function to sit in memory and wait to be called is not exactly the best idea..

Better though than the above would be just to define $userMessage as an Array(), catching whatever messages (exceptions, whatever), and then using that array to display messages. I would put it in the destruct() myself and have it report however I wanted.

Also, you said you were extending the Exceptions class to customize it, but you didn’t do any customization at all to the Exceptions class. Finally, the “final” keyword isn’t suposed to be the same as public/private/protected. Not to mention that if the Exceptions class was defined as “final”, trying to extend isn’t theoretically suposed to work.

I think you may want to reconsider a lot of the above article as it may be misleading to many…

Thanks for sharing, good article!

When it comes to logging an exception, I’ve come to find useful to do it in such a way that an unique global application “exception code” is attached to the exception info. Something like this in your app:

try {
// Do something that can throw a Zend_Xxx_Exception
}
catch (Zend_Xxx_Exception $e) {
BasicClass::logException(3001, $e);
}

Then you log it this way in your BasicClass::logException()
method:

public static function logException($exceptionCode = 0, $exception)
{

// Do custom exception formatting stuff…

$exceptionInfo = get_class($exception).’ Code ‘ . (int) $exceptionCode . ‘; Msg: “‘ . $exception->getMessage() . ‘”‘;

$zfLogger->log($exceptionInfo, Zend_Log::ERR, $exception->getFile(), $exception->getLine());
}
}

This global application exception code approach is used in some big companies and is really useful for later troubleshooting.