As I explained earlier, this final article will be focused on extending the functionality of the error logging system that I created in the previous part by applying a proper chain of responsibility schema.

Since this sounds pretty simple, I'll start listing the base error logging classes, which sit on top of the mentioned responsibility chain. Here is the signature of the two classes that I referenced above:

// define abstract 'AbstractErrorLogger' class on top of the
responsibility chain
abstract class AbstractErrorLogger{
    abstract public function setErrorLogger($errorLogger);
    abstract public function getErrorLogger();
    abstract public function logError();
}
// define concrete 'ErrorLogger' class
class ErrorLogger extends AbstractErrorLogger{
    private $errorLogger;
    public function __construct(){
        $this->errorLogger=NULL;
    }
    // get error logger
    public function getErrorLogger(){
        if($this->errorLogger==NULL){
            throw new Exception('No error logger has been set!');
        }
        return $this->errorLogger;
    }
    // set error logger
    public function setErrorLogger($errorLogger){
        $this->errorLogger=$errorLogger;
    }
    public function logError(){}
}

As you'll possibly remember, the above two error logging classes establish the top of the corresponding responsibility chain, from which all the eventual subclasses will be derived. Basically, the first abstract class defines the generic model of any possible error logger, while the second one implements concretely most of the abstract methods declared previously.

So far, the respective definitions of the above base classes aren't difficult to understand. However, it's worthwhile to stress here the way that the "getErrorLogger()" method works. As you can see, this method sets up the top of the responsibility chain when handling an error, because if the appropriate error logger  has not been defined (represented by the condition $this->errorLogger==NULL), then it throws an exception and program execution will be eventually halted.

From this point on, all the sub classes created from the previous "ErrorLogger" class will stick to the following logic: if a particular error condition can be properly handled by the class in question, then the error will be automatically transferred to its nearest parent, which as you saw a few lines above, will trigger an exception. That's what I call a well-defined chain of responsibility between a few PHP classes!

All right, after explaining the fairly relevant role played by the two pair of error classes created before, it's time to learn how the core error logging system can be expanded to register more specific failures.

In this particular case, I'll simply derive a child class from the parent "ErrorLogger," which will be provided with the capacity to register specific errors to the system's error logger.

In addition, based upon the correct application of the chain of responsibility schema, this new class will delegate the handling of a specific error to its parent, when this failure can be processed at the current level.

To learn more about how this new error logging class will be created, please keep reading.