PHP Comments – Are Docblock Typehints Redundant with Strict Typing?

It looks like you are having a design issue here: Tables should not extend the Database Abstraction Layer. Instead the DAL should be injected into the table as a dependency.

abstract class Table {
    protected $dal;

    public function __construct(DAL $dal) {
        $this->dal = $dal;
    }

    // whatever else all tables have in common
}

class Table_User extends Table {
    public function someMethod() {
        $this->dal->someOtherMethod();
    }
}

$table = new MyTable($dal);
$table->someMethod();

That way you will create a DAL at some upper scope and pass it down. This will also allow you to use multiple different database engines at the same time.

Additionally you obviously should not create your tables directly in your controller but let a specialized class do that. For example you could use a factory:

class TableFactory {
    protected $dal;

    public function __construct(DAL $dal) {
        $this->dal = $dal;
    }

    public function createTable($name) {
        $className = 'Table_' . $name;
        return new $className($this->dal);
    }
}

That way you can create a table factory at some point with an injected DAL and pass that table factory around.

$table = $factory->createTable('User');

In short, the only time you should log the existence of an exception is when you are handling it.

When you throw an exception, it is because your code has reached a state where it can not proceed correctly. By throwing an exception, you are representing a specific message to your program about the error that occurred. You should not catch an exception until you are at a point where it can properly be handled.

The code you write as part of your main application should be aware of the types of exceptions that can be thrown and when they might be thrown. If you can't do anything productive with an exception, don't catch it. Do not log an exception until it is being handled. Only the handling code knows what the exception means in the context of the program flow and how to respond to it. Writing a log message here may make sense here. If you use a logging framework, you can set a log level for the message and potentially filter them. This works well for exceptions that can occur, but are not critical and can be recovered from cleanly.

Your exception catch-all, is your last ditch effort to keep your code from crashing an ugly death. If you have gotten this far, you log all the state and error information you can. Then you do your best to nicely tell the user that the program is crashing before everything stops. Your goal should be to never have this code executed.

Embedding logging into the base class does not follow the above guidelines. The base class doesn't know anything about the state of the code. (Having the stack trace doesn't count because you are not going to write code that makes decisions based on parsing it.) The base class can't do anything to indicate the severity or how the exception might be handled. You don't want huge data dumps and stack traces every time there is a simple exception that you can handle and recover from cleanly.