Tach!
Untenstehend eine Basisklasse, aus welcher für sprezielle Aufgaben weitere Klassen abgeleitet werden können.
class MySQL{
Nicht nur, dass du einfach von PDO erben und somit dessen Funktionsumfang direkt nutzen könntest, statt für alles Wrapperfunktionen bereitstellen zu müssen, machst du aus der von PDO betriebenen Abstraktion über viele DBMSe wieder eine Konkretisierung auf nur ein einzelnes DBMS. Warum nimmst du dann nicht gleich mysqli als Basis, wenn du nur den MySQL-Teil haben willst?
Das Beispiel zeigt auch das Exception-Chaining. Deswegen ja auch eine eigene Klasse, weil es eine PDOException geben könnte (DB-Server wech) und in der eigenen Anwendungs-Klasse mit Exception gearbeitet wird; eine etwaige PDPException wird an die Klasse Exception 'durchgereicht'.
Damit erreichst du, dass man im übergeordneten Programmteil nicht mehr speziell auf PDOExceptions reagieren kann, stattdessen nur noch die ganz allgemeine Exception zur Verfügung hat, die noch bei einer Menge anderer Probleme geworfen werden könnte (nicht in diesem Fall hier, aber wenn man mal das System weiter ausbauen will, kommt das irgendwann zum Tragen). Es ist manchmal sinnvoll, spezielle Exceptions in andere Exceptions einzupacken, dann aber sicher nicht in die ganz allgemeine Exception-Klasse.
catch(PDOException $e){ throw new Exception($e->getMessage());
Seit PHP 5.3 kann man auch richtiges Exception Chaining verwenden. "Richtiges" unterscheidet sich von deiner Varianten, dass nicht nur die Message durchgereicht wird sondern dass die gesamte ursprüngliche Exception als Eigenschaft der neuen Exception gespeichert wird.
Das Einpacken und Neu-Werfen gibt zudem an den Aufrufer in den Eigenschaften für Line und File die neue throw-Zeile an. Das Reduzieren auf den Meldungstext macht somit auch das Indentifizieren der ursprünglichen Stelle schwerer, weil diese Information aus der alten Exception verloren geht - und das hier auch noch völlig ohne Not. Das heißt also, so wie du das zeigst, baust du dir nur Nachteile in den Code.
dedlfix.