Fatal error: Unccaught exception 'PDOException'...

[bubble]

Hi,

ich habe mir eine simple Wrapper-Klasse für MySQL via PDO gebastelt.

Nun beim testen viel mir auf, dass eine PDOException nicht abgefangen wird.

Der relevante Code:

		try {  
			$stmt = $this->dbh->prepare($sql);  
			$stmt->execute($data); // Laut stack trace wird hier die PDOException geworfen  
			return $stmt;  
		}  
		catch(Exception $e) {  
			$this->error = $e;  
			return false;  
		}

Sollte dieser try-catch-Block nicht eigentlich alle Exceptions abfangen?

Wo liegt mein Denkfehler?

MfG
bubble

[Matze]

Hallo!

Nun beim testen viel mir auf, dass eine PDOException nicht abgefangen wird.
Sollte dieser try-catch-Block nicht eigentlich alle Exceptions abfangen?

Du zeigst auf deinen Fehler

Wo liegt mein Denkfehler?

aber siehst ihn nicht. Exception != PDOException

catch(PDOException $objPDOE)

Grüße, Matze

[bubble]

aber siehst ihn nicht. Exception != PDOException
catch(PDOException $objPDOE)

Aber ...
"PDOException extends RuntimeException" -> "RuntimeException extends Exception"
... im Grunde ist es doch eine Exception. Geht das dann unter PHP generell nicht, dass man "Sub-Exceptions" über die Basisklasse abfangen kann?

MfG
bubble

[Matze]

Hallo!

"PDOException extends RuntimeException" -> "RuntimeException extends Exception"
... im Grunde ist es doch eine Exception. Geht das dann unter PHP generell nicht, dass man "Sub-Exceptions" über die Basisklasse abfangen kann?

Die PDOException extended zwar über Umwege die Exception, hat aber andere Rückgabewerte und wird entsprechend anders behandelt-

Schau dir mal den ersten User-Comment auf der verlinkten Seite zur PDOException an. Dort erklärt er dir wie du die Exceptions auch "durchschleifen" kannst.

Grüße, Matze

[bubble]

"PDOException extends RuntimeException" -> "RuntimeException extends Exception"
... im Grunde ist es doch eine Exception. Geht das dann unter PHP generell nicht, dass man "Sub-Exceptions" über die Basisklasse abfangen kann?

Die PDOException extended zwar über Umwege die Exception, hat aber andere Rückgabewerte und wird entsprechend anders behandelt-
Schau dir mal den ersten User-Comment auf der verlinkten Seite zur PDOException an. Dort erklärt er dir wie du die Exceptions auch "durchschleifen" kannst.

Nach dem ich deine Erklärung dafür recht sonderbar fand hab ich ein wenig rumgetestet... Und dann ist mir mein eigentlicher Fehler, den man so im gezeigten Quelltext nicht sehen kann aufgefallen (Ich dachte der Rest sei Irrelevant).

Das User-Kommentar hatte ja eher was mit der Verarbeitung der Daten der (PDO-)Exception zu tun, als die reine Klassenabstraktion.

Um meinen Fehler zu verdeutlichen hier mal der _wirklich_ relevante Code:

``{:.language-php<?php

namespace CMS\core;

use api\ecobd\nucleo\Conexion, PDO;

class DB {
/* ... /
private function runQuery($sql, $data) {
/ ... */
try {
$stmt = $this->dbh->prepare($sql);
$stmt->execute($data);
return $stmt;
}
catch(Exception $e) {
$this->error = $e;
return false;
}
}
}}

Dadurch, dass ich einfach nur catch(Exception $e) dazustehen hatte, wurde die Klasse CMS\core\Exception erwartet, von dieser Klasse ist natürlich PDOException keine "Sub-Klasse".

Ein führender Backslash catch(\Exception $e) brachte dann die Lösung.

Dank deinen Verweises auf das User-Kommentar ist mein nächstes Problem schon gelöst bevor es überhaupt aufgetaucht ist :D

MfG
bubble

[Matze]

Hallo!

Nach dem ich deine Erklärung dafür recht sonderbar fand hab ich ein wenig rumgetestet... Und dann ist mir mein eigentlicher Fehler, den man so im gezeigten Quelltext nicht sehen kann aufgefallen (Ich dachte der Rest sei Irrelevant).

Nanu, ich hätte erwartet, dass der catch-Block nicht triggert wenn er verschiedene Exceptions empfängt. Wofür man dann das Resultat von getCode() durch ein typecast ändert um aus einer PDOException eine "normale" Exception zu machen.
Irgendwas habe ich da wohl auch nicht verstanden :D

Dank deinen Verweises auf das User-Kommentar ist mein nächstes Problem schon gelöst bevor es überhaupt aufgetaucht ist :D

Immerhin war es nicht umsonst^^

Grüße, Matze

[bubble]

Nanu, ich hätte erwartet, dass der catch-Block nicht triggert wenn er verschiedene Exceptions empfängt. Wofür man dann das Resultat von getCode() durch ein typecast ändert um aus einer PDOException eine "normale" Exception zu machen.
Irgendwas habe ich da wohl auch nicht verstanden :D

Ja, was Datentypen angeht muss man bei PHP generell verdammt vorsichtig sein. Wenn es verschiedene Funktionssignaturen wären, wäre da schon beim kompilieren der Bibliothek der Fehler aufgetreten, da das aber nicht der Fall ist - und man nicht von einer speziellen Eigenheit PHPs ausgeht - kann es daran nicht liegen.

Selbst Funktionen die nichts zurück geben, vom Code her, geben etwas zurück:

  
function x(){}  
var_dump(x());

<kleiner_als_halbwissen>
Liefert "NULL". Da PHP ja auch nur in C (oder war es C++?) geschrieben ist, sind wohl alle Variablen irgendwie nur untypisierte Pointer und werden erst durch ihre kontextabhänige Verwendung typisiert bzw. versucht umzuwandeln.
</kleiner_als_halbwissen>

Immerhin war es nicht umsonst^^

Umsonst sind Antworten (fast) nie, es sei denn es ist irgendein Spammer am Werk!

MfG
bubble

[Matze]

Da PHP ja auch nur in C (oder war es C++?) geschrieben ist,

C, früher Perl.

Umsonst sind Antworten (fast) nie, es sei denn es ist irgendein Spammer am Werk!

Ich geb mein bestes damit aus dem einen nicht das andere wird :)

Grüße, Matze

[ChrisB]

Hi,

Nanu, ich hätte erwartet, dass der catch-Block nicht triggert wenn er verschiedene Exceptions empfängt.

Du kannst nach catch spezielle Typen von Exceptions angeben, um diese gezielt zu fangen – deshalb kannst du ja auch mehrere catch-Blöcke nach einem try schreiben, um verschiedenartige Exceptions, die darin auftreten könnten, gezielt einzeln zu behandeln.

Aber grundsätzlich sollte ein catch(Exception $e) *jede* Exception fangen, solange sie von der Basis-Exceptionklasse von PHP abgeleitet ist.

MfG ChrisB

[Matze]

Hallo!

Du kannst nach catch spezielle Typen von Exceptions angeben, um diese gezielt zu fangen – deshalb kannst du ja auch mehrere catch-Blöcke nach einem try schreiben, um verschiedenartige Exceptions, die darin auftreten könnten, gezielt einzeln zu behandeln.

Ja, das war mir bekannt. Daher kam halt die Vermutung, dass das so sein *muss*.

Aber grundsätzlich sollte ein catch(Exception $e) *jede* Exception fangen, solange sie von der Basis-Exceptionklasse von PHP abgeleitet ist.

Danke für deine Erklärung! Das beseitig tatsächlich auch einige Bäume bei meinem Blick auf den Wald.

Grüße, Matze

[Sven Rautenberg]

Moin!

Nanu, ich hätte erwartet, dass der catch-Block nicht triggert wenn er verschiedene Exceptions empfängt.

Du kannst nach catch spezielle Typen von Exceptions angeben, um diese gezielt zu fangen – deshalb kannst du ja auch mehrere catch-Blöcke nach einem try schreiben, um verschiedenartige Exceptions, die darin auftreten könnten, gezielt einzeln zu behandeln.

Aber grundsätzlich sollte ein catch(Exception $e) *jede* Exception fangen, solange sie von der Basis-Exceptionklasse von PHP abgeleitet ist.

Es ist sogar noch schlimmer: Du kannst ein Objekt nicht als Exception werfen, wenn es NICHT von "\Exception" erbt.

Und was die Auswertung der Exception angeht: Die allgemeine Exception bringt ein paar Funktionen mit, die man auch nicht überschreiben darf (final deklariert), insofern kann man sich beim Fangen von "\Exception" drauf verlassen, dass deren Minimalset an Funktionen existiert und benutzt werden kann.

- Sven Rautenberg

[Matze]

Hallo!

Es ist sogar noch schlimmer: Du kannst ein Objekt nicht als Exception werfen, wenn es NICHT von "\Exception" erbt.

Jetzt einfach mal ungetestet gefragt...
Trifft das auch zu wenn man eine Exception nachbildet ohne über die Vererbung zu gehen?
Im Prinzip also jede Logik entfernt und nur ein Objekt wirft welches die selben Methoden und Attribute besitzt?

Würde das "funktionieren"? Mal davon abgesehen ob das nun sinnvoll ist oder nicht.

Grüße, Matze

[dedlfix]

Tach!

Du kannst ein Objekt nicht als Exception werfen, wenn es NICHT von "\Exception" erbt.
Trifft das auch zu wenn man eine Exception nachbildet ohne über die Vererbung zu gehen?
Im Prinzip also jede Logik entfernt und nur ein Objekt wirft welches die selben Methoden und Attribute besitzt?

Es wäre viel zu aufwendig, bei einem Objekt alle Methoden und Eigenschaften durchzutesten, wenn man ein einfaches Ableiten von einer Klasse oder Interface prüfen kann. Dass der Rest stimmt, wird vom System (hier PHP) sichergestellt.

Würde das "funktionieren"?

Als es noch keine Interfaces in PHP gab, musste man sich so behelfen. Da PHP das nicht mehr tun muss, funktioniert es also nicht.

dedlfix.

[Matze]

Hallo!

Als es noch keine Interfaces in PHP gab, musste man sich so behelfen. Da PHP das nicht mehr tun muss, funktioniert es also nicht.

Ja aber in dem Fall handelt es sich ja nicht um ein Interface. Fragt PHP also intern ab ob eine Exception tatsächlich von der Exception-Klasse erbt anstatt nur die Signatur der Klasse zu überprüfen? Oder halt im Falle eines Interface, wird auf das Interface geprüft und nicht auf die vorhandenen Funktionen?
Ich gebe auch gerne zu, dass ich den Sinn hinter Interfaces nie verstanden habe. Für mich ist das einfach nur doppelter Code. Oder ich habe es nie gebraucht und kann den Nutzen deshalb nicht so ganz nachvollziehen...

Grüße, Matze

[dedlfix]

Tach!

Fragt PHP also intern ab ob eine Exception tatsächlich von der Exception-Klasse erbt anstatt nur die Signatur der Klasse zu überprüfen? Oder halt im Falle eines Interface, wird auf das Interface geprüft und nicht auf die vorhandenen Funktionen?

Aller Wahrscheinlichkeit nach ja. Es ist nicht sinnvoll, das während der Laufzeit ausführlich zu testen, wenn der Compiler schon geprüft hat, ob die Klasse alle Dinge des Interfaces implementiert oder durch Vererbung sichergestellt ist, dass alles da ist (zuzüglich Überschreiben der abstrakten Mitglieder).

Ich gebe auch gerne zu, dass ich den Sinn hinter Interfaces nie verstanden habe. Für mich ist das einfach nur doppelter Code. Oder ich habe es nie gebraucht und kann den Nutzen deshalb nicht so ganz nachvollziehen...

Ein Interface ist die Versicherung, dass bestimmte Mitglieder vorhanden sind. Der Compiler prüft das und das Programm kann darauf bauen.

dedlfix.

[Sven Rautenberg]

Moin!

Als es noch keine Interfaces in PHP gab, musste man sich so behelfen. Da PHP das nicht mehr tun muss, funktioniert es also nicht.

PHP 4 hat nahezu keine interessanten OOP-Features implementiert gehabt, lediglich simple Vererbung. Ich glaube kaum, dass man in diesem mangelhaften Zustand Interfaces simulieren wollte - man kann ja nur von genau einer Klasse erben, man kann aber parallel mehr als ein Interface implementieren.

Ich denke aber auch, dass es nicht sinnvoll ist, sich über diese alte PHP-Version noch Gedanken zu machen.

Ja aber in dem Fall handelt es sich ja nicht um ein Interface. Fragt PHP also intern ab ob eine Exception tatsächlich von der Exception-Klasse erbt anstatt nur die Signatur der Klasse zu überprüfen? Oder halt im Falle eines Interface, wird auf das Interface geprüft und nicht auf die vorhandenen Funktionen?

Die Exception ist eine Klasse mit diversen finalen Methoden, die man nicht überschreiben kann. Ganz offensichtlich muss eine werfbare Exception die Prüfung $exception instanceof \Exception bestehen.

Ich gebe auch gerne zu, dass ich den Sinn hinter Interfaces nie verstanden habe. Für mich ist das einfach nur doppelter Code. Oder ich habe es nie gebraucht und kann den Nutzen deshalb nicht so ganz nachvollziehen...

Interfaces sind Vereinbarungen über die Existenz von Methoden.

Wenn du dir mal ein sehr einfaches Interface ansiehst:

interface \Countable {  
     public function count();  
}  

Das ist funktionsmäßig nicht der Wahnsinn, aber der Zweck (ohne Beachtung der PHP-internen Magie) ist recht simpel:

Wenn du als Typehint in einer Funktion forderst, dass ein Parameter vom Typ "Countable" ist, dann kannst du dieser Funktion nur Objekte übergeben, die dieses Interface implementieren. Innerhalb dieser Funktion ist dann garantiert, dass du bei dem Objekt die Methode "count" aufrufen kannst. Nicht garantiert ist, welche anderen Methoden du an dem Objekt noch aufrufen kannst. PHP prüft an dieser Stelle den Typehint nicht und verhindert Aufrufe typfremder Methoden nicht (anders als Java).

Als Codebeispiel:

public function addiereAnzahl(Countable $objekt) {  
    $this->summe = $this->summe + $objekt->count();  
    return $this->summe;  
}  

PHP hat für dieses Interface eigene Magie eingeführt: Wenn man count($objekt) aufruft, und das Objekt das Countable-Interface implementiert, wird die count-Funktion aufgerufen und die zurückgegebene Zahl als Funktionsergebnis von count() zurückgegeben. Ein Objekt, welches nicht Countable implementiert, gibt beim Funktionsaufruf immer 1 zurück.

Obwohl es hier um die etwas merkwürdige Überlappung von Objektorientierung mit prozeduraler Programmierung geht (count ist ja "nur" eine normale Funktion), demonstriert es ein wichtiges Feature von Interfaces: WENN das Interface implementiert wurde, dann MÜSSEN alle Interface-Funktionen existieren, und dann kann man sie auch jederzeit aufrufen. Bei der Funktion "count" wird das dynamisch erkannt, bei dem Beispiel oben MUSS man es tun.

Nun ist es irrelevant, irgendwelche Interfaces zu implementieren, wenn man sowieso nur genau eine Klasse von irgendwas hat. Spannend wird's aber, wenn man verschiedene Klassen hat, die alle so ungefähr dasselbe tun, aber in den Details eben doch unterschiedlich.

Das Countable-Interface ist beispielsweise geschaffen worden, um Objekte so behandeln zu können, wie Arrays (der wichtigere Rest steckt im ArrayAccess-Interface). Objekte machen die unterschiedlichsten Dinge, aber weil man eventuell eine Reihe von Objekten hat, die eine Liste oder ein Array von weiteren Objekten enthalten, und man deren Anzahl erfahren will, ist dieses Interface prima: Wie man die Anzahl zu ermitteln hat, ist stark vom eigentlichen Objekt abhängig, aber die Details interessieren die Außenwelt nicht - die will nur wissen, wie sie an die Anzahl kommt. Und anstatt jetzt pro Objekt irgendeine beliebig benannte Funktion zu erfinden, kann man eben einfach auch Countable implementieren, das für genau diese Aufgabe geschaffen wurde.

Und wenn ein Typehint lediglich "Countable" fordert, sagt er: Mir egal, was das Objekt sonst noch an Methoden kann, ich bin ausschließlich daran interessiert, dass ich die Methode "count" am Objekt aufrufen kann und eine Anzahl bekomme.

- Sven Rautenberg

[Matze]

Hallo!

Ach wie mich deine Erklärung gerade frustriert...
Keine Angst, ich habe sie verstanden...

Ich wusste nichtmal, dass PHP type hinting kennt.

Ich versuche gerade eine etwas komplexere Anwendung zu schreiben und je öfter ich mal wieder hier ins Forum schaue, desto mehr zweifele ich daran ob ich der Aufgabe überhaupt gewachsen bin. Am Ende wird wohl alles so funktionieren wie es soll aber irgendwie geht das eigentlich auch alles viel "schöner". Ich hänge der Entwicklung von PHP irgendwo hinterher.

Herzlichen dank für deine ausführliche Erklärung!

Grüße, Matze

[Matze]

Hallo!

Ich wusste nichtmal, dass PHP type hinting kennt.

Und wie es ausschaut noch nichtmal vollständig. Die primitiven Datentypen (integer, string, boolean etc.) wurden vergessen oder täusche ich mich?

@Sven:

Der Codingstandard PSR-2 fordert, für alle Methoden den Sichtbarkeitsmodifizierer anzugeben - auch in Interfaces.

PHP erledigt das auch ohne dein Zutun.
"Methoden ohne jede explizite Deklaration sind als public definiert."

Ob das nun gut oder schlecht ist, ist eine andere Frage. Man muss es zumindest nicht zwingend angeben.

Grüße, Matze

[dedlfix]

Tach!

Ich wusste nichtmal, dass PHP type hinting kennt.
Und wie es ausschaut noch nichtmal vollständig. Die primitiven Datentypen (integer, string, boolean etc.) wurden vergessen oder täusche ich mich?

Bei Primitiven (Skalaren) ist es nicht besonders sinnvoll, wegen der automatischen Typumwandlung. Auch Arrays wurden erst nachträglich hinzugefügt. Resourcen und Traits können ebenfalls nicht verwendet werden.

Der Codingstandard PSR-2 fordert, für alle Methoden den Sichtbarkeitsmodifizierer anzugeben - auch in Interfaces.
PHP erledigt das auch ohne dein Zutun.
Ob das nun gut oder schlecht ist, ist eine andere Frage. Man muss es zumindest nicht zwingend angeben.

Der Codingstandard ist kein Gesetz. Es bleibt sinnlos, auch wenn es nun einheitlich aussieht. Aber welchen Nutzen hat das?

dedlfix.

[Matze]

Hallo!

Bei Primitiven (Skalaren) ist es nicht besonders sinnvoll, wegen der automatischen Typumwandlung. Auch Arrays wurden erst nachträglich hinzugefügt. Resourcen und Traits können ebenfalls nicht verwendet werden.

Man kann in PHP ja auch nach Typ prüfen (=== und Konsorten).
Die automatische Typumwandlung könnte man also aussen vor lassen. Ich weiß aber nicht wie PHP das type hinting intern löst. Mit anderen Worten, dass
function(boolean $blnVar){/*..*/}
ungültig ist aber

function($blnVar){  
  if($blnVar === true || $blnVar === false) /*..*/ ;  
}

gültig ist, ergibt für mich erstmal wenig Sinn.

Der Codingstandard ist kein Gesetz. Es bleibt sinnlos, auch wenn es nun einheitlich aussieht. Aber welchen Nutzen hat das?

Ich würde an der Stelle dem Argument "auch wenn es nun einheitlich aussieht" gar nicht mal so wenig Bedeutung schenken und kann Sven seinen Einwand deshalb auch gut nachvollziehen. Übersichtlichkeit und Vereinheitlichung sollte man nicht unterbewerten.

Grüße, Matze

[dedlfix]

Tach!

Bei Primitiven (Skalaren) ist es nicht besonders sinnvoll, wegen der automatischen Typumwandlung. Auch Arrays wurden erst nachträglich hinzugefügt. Resourcen und Traits können ebenfalls nicht verwendet werden.
Man kann in PHP ja auch nach Typ prüfen (=== und Konsorten).

Damit kann man neben der Werte(un)gleichheit explizit _auch_ auf Typ(un)gleichheit prüfen, ohne dass eine automatische Umwandlung stattfindet, ja ...

Die automatische Typumwandlung könnte man also aussen vor lassen.

... die Frage ist allerdings, wie PHP bei Funktionsaufrufen damit umgehen soll und was die Antwort auf die 80/20-Frage ist. Was wollen 80% der Anwender? Soll das Argument getypecastet werden, wenn es nicht dem geforderten Typ entspricht? Oder soll PHP mehr in Richtung typsicherer Sprache mutieren, indem es an der Stelle falsche Typen abweist? Bei Klassen und Interfaces kann man noch damit argumentieren, dass der Typehint aufgrund der Individualität der Klassen/Interfaces sehr sinnvoll ist. Hier muss man dem Ruf nach einigermaßen verwendbaren OOP Gehör schenken. Aber bei den Primitiven sollte man der Natur PHPs ihren Lauf lassen und automatisch umwandeln. Spätestens im Body der Funktion/Methode schlägt ja dann doch wieder der Automatismus zu.

Der Codingstandard ist kein Gesetz. Es bleibt sinnlos, auch wenn es nun einheitlich aussieht. Aber welchen Nutzen hat das?
Ich würde an der Stelle dem Argument "auch wenn es nun einheitlich aussieht" gar nicht mal so wenig Bedeutung schenken und kann Sven seinen Einwand deshalb auch gut nachvollziehen. Übersichtlichkeit und Vereinheitlichung sollte man nicht unterbewerten.

Damit ist man zwar PHP-intern einheitlich, aber unterschiedlich zu zum Beispiel C#, bei dem das nicht gestattet ist. Das ist besonders für Wandler zwischen den Welten ärgerlich. Als nächtes könnte man noch auf die Idee kommen, Blocksatz wegen des einheitlichen rechten und linken Randes zu fordern ... Sinnlose Forderungen kann man ruhig als solche brandmarken und muss sie sich nicht schönreden.

dedlfix.

[dedlfix]

Tach!

Als es noch keine Interfaces in PHP gab, musste man sich so behelfen. Da PHP das nicht mehr tun muss, funktioniert es also nicht.
PHP 4 hat nahezu keine interessanten OOP-Features implementiert gehabt, lediglich simple Vererbung. Ich glaube kaum, dass man in diesem mangelhaften Zustand Interfaces simulieren wollte - man kann ja nur von genau einer Klasse erben, man kann aber parallel mehr als ein Interface implementieren.

Damals gab es nur die Möglichkeit, mit method_exists() oder is_callable() zu prüfen, ob eine Klasse eine bestimmte Methode hat (nebst isset() für Eigenschaften). Das ist ja das, was Matze vorschlug, um ebendies zu prüfen. Das ist mit Interfaces (für Methoden) nun obsolet geworden. Deshalb nehme ich an, dass aktuelles PHP lediglich auf instanceof InterfaceName prüft und der Interface-Mechanismus vorher bereits die "Drecksarbeit" der Vorhandenseinprüfung erledigt hat.

Ich denke aber auch, dass es nicht sinnvoll ist, sich über diese alte PHP-Version noch Gedanken zu machen.

Find ich auch, und deswegen kann man auch die alten Einzelprüfmöglichkeiten zugunsten von Interfaces, Vererbung und Type Hinting ad acta legen.

Wenn du dir mal ein sehr einfaches Interface ansiehst:

interface \Countable {

public function count();
}

  
Kleine Ergänzung am Rande: Interfaces definieren stets öffentliche Mitglieder. Ein public zu notieren ist zwar (im Gegensatz zu C# beispielsweise) möglich aber nicht besonders nützlich.  
  
  
dedlfix.

[Sven Rautenberg]

Moin!

Kleine Ergänzung am Rande: Interfaces definieren stets öffentliche Mitglieder. Ein public zu notieren ist zwar (im Gegensatz zu C# beispielsweise) möglich aber nicht besonders nützlich.

Der Codingstandard PSR-2 fordert, für alle Methoden den Sichtbarkeitsmodifizierer anzugeben - auch in Interfaces.

Und es ist auch eine gute Signalisierung von PHP5-OOP.

- Sven Rautenberg

[Sven Rautenberg]

Moin!

Es ist sogar noch schlimmer: Du kannst ein Objekt nicht als Exception werfen, wenn es NICHT von "\Exception" erbt.

Jetzt einfach mal ungetestet gefragt...
Trifft das auch zu wenn man eine Exception nachbildet ohne über die Vererbung zu gehen?
Im Prinzip also jede Logik entfernt und nur ein Objekt wirft welches die selben Methoden und Attribute besitzt?

Das Manual sagt:

"The thrown object must be an instance of the Exception class or a subclass of Exception. Trying to throw an object that is not will result in a PHP Fatal Error."

Insofern: Nein, das "Nachbilden" funktioniert nicht, du mußt echt eine Instanz von \Exception werfen, oder eine davon erbende Klasse.

Einfach nur in einer Klasse dieselben Methoden zu implementieren reicht nicht aus. Ich vermute mal, ohne es am Code belegen zu können, dass eine Exception-Instanz interne PHP-Magie enthält, die beispielsweise für den in der Exception enthaltenen Stacktrace sorgt, sowie für das Gefangenwerden in Catch-Blöcken bzw. das finale Scheitern beim Nichtfangen.

Da try/catch ein Sprachkonstrukt ist, finde ich es nur normal, wenn die Exception-Klasse, von der alles erben muss, ebenfalls "besonders" ist.

- Sven Rautenberg