Jump to content

Recommended Posts

Hi All,

 

which is the better way to do the database connection:

<?php
# display all php errors
error_reporting(-1);
ini_set('display_errors', 1);

try
{
	$dbConnection = new PDO('mysql: host=localhost; dbname=jokesdb', 'root', 'password');
	$dbConnection -> setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
	$dbConnection -> exec('SET NAMES "utf8"');
}
catch (PDOException $e)
{
	$status = 'Unable to connect to the database server.' . '<br />' . $e -> getMessage();
	include 'status.php';
	exit();
}

$status = 'Database connection established';
include 'status.php';
?>

 

 

or is it better to use:

<?php
	# display all php errors
	error_reporting(-1);
	ini_set('display_errors', 1);

	$host = 'localhost';
	$database   = 'db';
	$username = 'root';
	$password = 'password';
	$charset = 'utf8';
	$option = array(
		PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
		PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC
	);
	
	$dataSource = 'mysql:host=' . $host . ';dbname=' . $database . ';charset=' . $charset;
	$dbConnection = new PDO($dataSource, $username, $password, $option);
?>

Thoughts?

Edited by dudleylearning
Link to comment
https://forums.phpfreaks.com/topic/302848-pdo-db-connection-use-try-catch-or-not/
Share on other sites

I'm not sure why PHP programmers are so obsessed with PDO exceptions.

 

A PHP script can generate dozens or even hundreds of different exceptions, errors, warnings and notices. What about those? If you wanted to handle each one of them individually like you do with PDOException, you'd have to write an error handler for almost every line of code. And then you still haven't done anything about the errors which happen before runtime. This obviously makes no sense. If you display the error messages to the user (which many programmers like to do for some reason), that's even dangerous, because they often contain sensitive information about your application or system.

 

So what we do instead is set up a global error handler. The default handler actually works very well, so most of the time, you have to do nothing but configure your php.ini appropriately: In production, you disable display_errors and enable log_errors. This writes all errors to a logfile and at the same time emits a 500 status code which can be used to display a user-friendly error page (“Sorry, but there was an internal error. The administrator has been notified.” etc.). During development, you enable display_errors so that you can see all revelant information (not just the message!) directly on the screen. What more do you need?

 

Catching an exception is only valid when you have a specific error handling strategy for this specific problem, which is very, very rare. For example, in some cases it makes sense to retry the action or switch to a backup routine. But most of the time, you just want to make the error information available to the developers and display a nice page for the users.

Edited by Jacques1
  • Like 1

I'm not sure why PHP programmers are so obsessed with PDO exceptions.

 

It's probably because every PDO tutorial out there does the "Try/Catch show user the system error " way of doing it. I used to do that as well until I was schooled by @Jaques1 on the proper way with set_error_handler. The only place I use a try/catch now is on duplicate username on registration.

Edited by benanamen

It's probably because every PDO tutorial out there does the "Try/Catch show user the system error " way of doing it.

 

Unfortunately, even the PHP manual teaches this practice in the example code. The fact that PDO defaults to using two entirely different error handling mechanisms depending on the method isn't helpful either. So the constructor throws an exception which should not be handled, but then all other methods use return values which must be handled – unless exceptions are turned on, in which case the other methods throw exceptions as well.

 

It's like they want programmers to screw up. ::)

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.