mehrfachvererbung - extends - oder im Konstruktor?

[unset]

Ich wollt's grade editieren. Das war mein Fehler. Da hab ich mal nur quergelesen und das "throw" im falschen Block gesehen :-) Trotzdem: Lies den von mir verlinkten Artikel. Verstehe, was Exceptions machen!

[phpMorpheus2]

Ich wollt's grade editieren. Das war mein Fehler. Da hab ich mal nur quergelesen und das "throw" im falschen Block gesehen :-) Trotzdem: Lies den von mir verlinkten Artikel. Verstehe, was Exceptions machen!

Danke
Den Artikel hatte ich damals bereits gelesen.
Lese aber gerne. Also ran da

[phpMorpheus2]

Sitzt der "fänger" jedoch nicht in der immer aktiven index.php, sondern in den einzelnen ActionView wie profil.php,
so muss für jede ActionView das ExceptionCatch Gerüst zum größten Teil kopiert werden..

Dazu: Gibt es auch eine Art Exception für Erfolgreiche vorgänge?
Jedoch mit additionsfunktion?
Sodass nicht direkt in den catch gesprungen, sondern gesammelt wird?
Ich benutze dafür eine seperate Klasse bislang.

[onemorenerd]

Wofür benutzt du deine separate Klasse? Gib mal ein echtes Beispiel.

[phpMorpheus2]

Wofür benutzt du deine separate Klasse? Gib mal ein echtes Beispiel.

Entschulding. Natürlich.

Also wenn z.B. ein User ein Bild uploaded, so bekommt er die positive Meldung, das es gespeichert wurde.
Hat er das Bild nun als Profilfoto upgeloaded, so bekommt er die positive Meldung, dass das bild gespeichert wurde UND in der selben Meldung darunter noch die Zusatzvermerkung, dass es nun als Profilfoto gespeichert wurde.

Bei jedem Erfolgreichem Durchlauf der Aktionen speichern bestimmte Klassenmdethoden positive Meldungen, welche der User Empfangen soll.
Diese addieren sich ggf. (falls mehrere mal vorhanden sind, was auch vorkommt!) und werden wie gesagt zusammen ausgegeben.

[onemorenerd]

Das sind keine Ausnahmen. Es ist nichts unvorhergesehenes passiert, so dass das Programm nicht weiter machen kann.
Das sind einfache Mitteilungen an den Benutzer.

Wenn man schön EVA macht, kann man während des E und V alle Meldungen sammeln und beim A anzeigen.
Dir dient die separate Klasse als Körbchen zum Sammeln. Super.
Aber wo erzeugst du die Ausgabe? Laut Bild in der class.user.php und das ist Mist.

Ich bin jetzt gedanklich wieder da, wo ich schon vor vielen Beiträgen war: class.user.php ist ein Model und als solches hat es keine Ausgaben zu machen.
Das letzte Mal hatte ich dazu einen Link zum Exceptions-Manual gegeben. Von Formularen und Validierung war in dem Bild nämlich nichts zu sehen.


Ich denke wir sollten uns nicht weiter an deinem Bild festhalten. Mach mal hübsches UML draus, dann verstehen wir uns besser.

[phpMorpheus2]

Nein.
Also die Ausgabe findet in der Action/view statt.
Also in der profil.php und nicht in der class.

Eine Klasse darf höchstens eine Nachticht zum sammeln abgeben, gezeigt wird aber von der view aus.

Zu den Exceptions:
EDIT: Man braucht garnicht vererben.
Das finde ich super.

[phpMorpheus2]

Das sind keine Ausnahmen. Es ist nichts unvorhergesehenes passiert, so dass das Programm nicht weiter machen kann.

Ist es denn auch "untersagt",
eine Exception zu werfen und auszugeben,
wenn z.B. der User ein Feld im Formular falsch oder garnicht ausgefüllt hat?
Das ist zwar "unerwartet", aber ich glaube nicht das es Status für eine Exception kriegt, oder doch?

Ich würde bei einer mehrfachvalidierung von z.B. Feldern eine extra Exception Klasse bauen welche
die Fehler nach und nach aufnimmt und zum schluss würde ich eine richtige Exception werfen welche
die Array der Fehler mitbekommt. ?!

[onemorenerd]

Untersagt ist es nicht, aber unschön. Was genau erhoffst du dir davon? Wo siehst du einen Vorteil?
Ich sehe zumindest einen Nachteil: Das

eine extra Exception Klasse bauen welche die Fehler nach und nach aufnimmt und zum schluss würde ich eine richtige Exception werfen welche die Array der Fehler mitbekommt

wird Gemurkse. Du musst ja stets zwischen Fehlermeldungen und echten Ausnahmen unterscheiden. Und zwar nicht nur in dem Catcher, der die Fehlermeldungen sammeln soll, sondern auch in jedem catch(Exception $e) zwischen throw und diesem. Das blickt am Ende keiner mehr.
Außerdem zwingt es dich, die Validatoren so atomar wie möglich zu machen. Jeder darf nur einen Test machen. Denn schlägt der fehl, wirfst du eine Exception, landest im Catcher und kannst nicht wieder zur Validierung "zurück springen". Um weitere Tests auszuführen muss die ganze Validierung irgendwie vom Catcher aus gesteuert werden ... da stellen sich bei mir die Nackenhaare auf!

[phpMorpheus2]

Ja, ich habe nun versucht in einem Kopie meines Projektes die Exceptions einzubauen und ich hab grad echt keine Lust mehr, das ist Kraut mit Rüben geworden. Da geht garnichts mehr.

Da arbeite ich lieber wieder ohne Exceptions, weil ich einfach die Rückgabewerte jeder Funktion benötige.

Mit Exceptions ist das nicht gegeben und vor allem ist es nervig dauernd im catcher zu landen.

Da mach ich mir nicht die Mühe, nun auchnoch zwischen Fehlermeldungen zu unterscheiden ob nun positiv, nagativ, neutral und wenn ja, als exception oder nicht und wenn als exception, wo kommt der block hin und was muss und soll alles im Try stehen.

Da hab ich am Ende mehr Arbeit mit. Nö nö
Darum habe ich immer die Finger von Exceptions gelassen.

Vll. in nem andern Quartal nochmal versuchen.