The Stack Overflow podcast is back! Listen to an interview with our new CEO.
2 Reworded several paragraphs to help clarity and fixed spelling errors
source | link

I would argue itsit's impossible to handle all exceptions the same way. I think you should let it propagate back to the calling code as itonly that ultimately knows how it shouldto handle the exceptional situation.

Just to think of a (maybe weird)As an example. Imagine imagine you have an blog. An eachEvery hour you query the database for new articles to populate a cache. But luck isn't with you and yourthe database is temporarily unavailable. Now youYou could throw anlet the exception go unhandled and the whole site is down (handle. You could also handle the exception inside the database abstraction layer and return a default result (effectively hiding the exception) or you. But returning a default value would overwrite the cache with nothing. The site is up, but doesn't work properly. You could also log the error, userethrow the exception to let the calling code decide what to do. The calling code could reuse the already cached query results, and extend the lifetime of the cache another hour hoping for the database to come back up. This way your users would to next to noexperience minimal disruption inof your site and may never even notice you had problems before you have fixed them.

So you can, howeverBut it isn't always easy to determine what to do in exceptional cases and sometimes it would preferable to just let the exception bubble up until it hits a generic exception handler, which displays a generic error page. You can in addition implement some general procedures if a query fails, likesuch as error logging in this generic exception handler. This would be preferable as this can be considered boilerplate code that doesn't change muchanything. And having database errorsunhandled exceptions emailed to you (as an example) lets you resolve the issue faster than if you were to discover the issue yourself.

You also get an additional bonus by grouping logginggeneric-logging code in onea single place. You can handle specific logging alongside relevant code (where details are available) and if your generic logging procedure should change you only need to change it once.

Using your fetchAll() method the structure could look like:

public function fetchAll($sql, $bind = array()) {

    // Do something awesome before try-catch block.

    try {

        // Execute query...

    }catch(PDOException $exception) {

        $this->logger->log('SQL query failed: ' . $exception->getMessage());

        /*
         * Re-throw the exception to let the calling code
         * handle the situation.
         */
        throw $exception

    }

    // Continue as everything executed as expected.

} 

Happy coding!

I would argue its impossible to handle all exceptions the same way. I think you should let it propagate back to the calling code as it ultimately knows how it should handle the exceptional situation.

Just to think of a (maybe weird) example. Imagine you have an blog. An each hour you query the database for new articles. But luck isn't with you and your database is temporarily unavailable. Now you could throw an exception and the whole site is down (handle the exception inside the database abstraction layer) or you could log the error, use the cached query results, extend the lifetime of the cache another hour. This way your users would to next to no disruption in your site and may never even notice you had problems before you have fixed them.

So you can, however, implement some general procedures if a query fails, like error logging. This would be preferable as this can be considered boilerplate code that doesn't change much. And having database errors emailed to you (as an example) lets you resolve the issue faster than if you were to discover the issue yourself.

You also get an additional bonus by grouping logging code in one place. You can handle specific logging alongside relevant code and if your generic logging procedure should change you only need to change it once.

Using your fetchAll() method the structure could look like:

public function fetchAll($sql, $bind = array()) {

    // Do something awesome before try-catch block.

    try {

        // Execute query...

    }catch(PDOException $exception) {

        $this->logger->log('SQL query failed: ' . $exception->getMessage());

        /*
         * Re-throw the exception to let the calling code
         * handle the situation.
         */
        throw $exception

    }

    // Continue as everything executed as expected.

} 

Happy coding!

I would argue it's impossible to handle all exceptions the same way. I think you should let it propagate back to the calling code as only that ultimately knows how to handle the exceptional situation.

As an example imagine you have an blog. Every hour you query the database for new articles to populate a cache. But luck isn't with you and the database is temporarily unavailable. You could let the exception go unhandled and the whole site is down. You could also handle the exception inside the database abstraction layer and return a default result (effectively hiding the exception). But returning a default value would overwrite the cache with nothing. The site is up, but doesn't work properly. You could also log the error, rethrow the exception to let the calling code decide what to do. The calling code could reuse the already cached query results and extend the lifetime of the cache another hour hoping for the database to come back up. This way your users would experience minimal disruption of your site and may never even notice you had problems.

But it isn't always easy to determine what to do in exceptional cases and sometimes it would preferable to just let the exception bubble up until it hits a generic exception handler, which displays a generic error page. You can in addition implement some general procedures if a query fails, such as error logging in this generic exception handler. This would be preferable as this can be considered boilerplate code that doesn't change anything. And having unhandled exceptions emailed to you (as an example) lets you resolve the issue faster than if you were to discover the issue yourself.

You also get an additional bonus by grouping generic-logging code in a single place. You can handle specific logging alongside relevant code (where details are available) and if your generic logging procedure should change you only need to change it once.

Using your fetchAll() method the structure could look like:

public function fetchAll($sql, $bind = array()) {

    // Do something awesome before try-catch block.

    try {

        // Execute query...

    }catch(PDOException $exception) {

        $this->logger->log('SQL query failed: ' . $exception->getMessage());

        /*
         * Re-throw the exception to let the calling code
         * handle the situation.
         */
        throw $exception

    }

    // Continue as everything executed as expected.

}
1
source | link

I would argue its impossible to handle all exceptions the same way. I think you should let it propagate back to the calling code as it ultimately knows how it should handle the exceptional situation.

Just to think of a (maybe weird) example. Imagine you have an blog. An each hour you query the database for new articles. But luck isn't with you and your database is temporarily unavailable. Now you could throw an exception and the whole site is down (handle the exception inside the database abstraction layer) or you could log the error, use the cached query results, extend the lifetime of the cache another hour. This way your users would to next to no disruption in your site and may never even notice you had problems before you have fixed them.

So you can, however, implement some general procedures if a query fails, like error logging. This would be preferable as this can be considered boilerplate code that doesn't change much. And having database errors emailed to you (as an example) lets you resolve the issue faster than if you were to discover the issue yourself.

You also get an additional bonus by grouping logging code in one place. You can handle specific logging alongside relevant code and if your generic logging procedure should change you only need to change it once.

Using your fetchAll() method the structure could look like:

public function fetchAll($sql, $bind = array()) {

    // Do something awesome before try-catch block.

    try {

        // Execute query...

    }catch(PDOException $exception) {

        $this->logger->log('SQL query failed: ' . $exception->getMessage());

        /*
         * Re-throw the exception to let the calling code
         * handle the situation.
         */
        throw $exception

    }

    // Continue as everything executed as expected.

} 

Happy coding!