Laden...

Kommunitkation zwischen Layern

Erstellt von yakuza vor 18 Jahren Letzter Beitrag vor 18 Jahren 3.311 Views
Y
yakuza Themenstarter:in
25 Beiträge seit 2005
vor 18 Jahren
Kommunitkation zwischen Layern

Ich will in Zukunft meinen Code schön strukturieren und in Layer teilen.
Wie die Trennung erfolgen soll weiss ich, aber ich habe folgendes Problem bei der Kommunikation zwischen den Layern.
Ich könnte aus dem UI-Layer eine Methode im darunter liegenden Layer aufrufen die mir einen boolschen Wert zurückliefert ob die Methode erfolgreich ausgeführt worden ist oder nicht. Bei einem 'false' habe ich aber keine weiterführenden Informationen warum der Methodenaufruf fehlgeschlagen ist. Ich könnte im Fehlerfall zwar eine Exception 'werfen', aber das ist ja aus (a) Performancegründen nicht gut und (b) auch kein guter Programmierstil.

Meine Idee wäre ein Struct 'boolString' welches aus einem boolschen Wert und einem String besteht. Somit hätte ich die Möglichkeit Fehlermeldungen nach oben transportieren zu können.
Leider wäre das eine Insellösung.

Darum die Frage an Euch wie Ihr das lösen würdet, oder wie Ihr das Problem gelöst habt.

Bin für jeden Tipp dankbar.

NUnit is your friend.

C
64 Beiträge seit 2005
vor 18 Jahren

Hi yakuza,

genau dafür sind Exceptions ja da, das mit der Performance halte ich ebenfalls für ein Märchen. Das ist m. E. auch kein schlechter Programmierstil, sonder der korrekte Weg wie man dies löst.

Grüße Sven

49.485 Beiträge seit 2005
vor 18 Jahren

Hallo yakuza,

Ich könnte im Fehlerfall zwar eine Exception 'werfen', aber das [...] (b)
auch kein guter Programmierstil.

Das Gegenteil ist der Fall. Für dein Beispiel ist jede andere Möglichkeit als Exceptions schlechter Programmierstil.

Siehe dazu auch: try catch errormessage

herbivore

6.862 Beiträge seit 2003
vor 18 Jahren

Wenn man Exceptions falsch, für jede Art von Fehlerbehandlung einsetzt können die schon auf die Performance gehen. Aber in deinem Fall nicht. Wenn ein Fehler auftritt in den Funktionen dann sollte das Programm auch nicht unbedingt weitermachen sondern den Fehler behandeln und schaun das die Funktion doch noch richtig ausgeführt wird. Und da spielt Performance nun wirklich keine Rolle, da ist die Fehlerbehandlung viel wichtiger. Was bringts dir sonst das du weißt das deine Funktion schief gelaufen ist, kannst aber nichts machen.

Baka wa shinanakya naoranai.

Mein XING Profil.

Y
yakuza Themenstarter:in
25 Beiträge seit 2005
vor 18 Jahren

Vielleicht habe ich mich falsch ausgedrückt.
Natürlich fange ich Exceptions ab, und je nach Exceptiontyp kann man die Problemursache auch eingrenzen.
Aber ich glaube nicht, dass es ratsam ist eine SQL-Exception soweit nach oben zu werfen bis ich im UI-Layer angekommen bin.
Ich würde lieber eine z.B. SQL-Exception untersuchen und dann nur noch ein 'false' und den Grund für die Exception in die oberen Layer weiterleiten, und ich weiss nicht wie ich das am besten machen soll.

NUnit is your friend.

49.485 Beiträge seit 2005
vor 18 Jahren

Hallo yakuza,

du ich verstehe jetzt dein Problem. Auch das kannst und solltest du mit Exceptions lösen. Das Stichwort ist InnerException.

Auf dem Weg von der Datenbank mit zum GUI werden in der Regel mehrere Methoden (auf den unterscheidlichen Sichten) beteiligt sein. Und je höher die Methode, desto näher ist sie an der Semanik des Benutzers dran und je tiefer die Methode desto näher ist sie einem techischen Detail der Umsetzung dran.

Je weiter oben eine Methode ist, desto mehr Informationen hat sie also darüber, was das Fehlschlagen eines technischen Details für die gesamte gerade ablaufende Aktion bedeutet. Entsprechend kann sie eine Exception mit einer entsprechenden Aussage werfen, der sie als InnerException die gefangene Exception mitgibt. Das kann übermehrere (Exception)-Stufen erfolgen. Dem Benutzer wird dann erstmal nur äußerste Exception präsentiert und erst auf Nachfrage nacheinander die inneren oder gleich die Innerste.

Beispiel: Äußerste Exception: "Speichern des Dokuments fehlgeschlagen.", innere Exception "Speichern der Verwaltungsinformation fehlgeschlagen", innerste Exception "SQ1798687: can't update DOKU_AUTHOR".

herbivore

Y
yakuza Themenstarter:in
25 Beiträge seit 2005
vor 18 Jahren

berbivore, ganau das wollte ich wissen.

Ich habe geglaubt, dass es hierfür eine andere Lösung gibt.
Dein Beispiel macht aber Sinn und so werde ich das wohl in der Zukunft machen.

Danke.

NUnit is your friend.

195 Beiträge seit 2004
vor 18 Jahren

Original von herbivore
Je weiter oben eine Methode ist, desto mehr Informationen hat sie also darüber, was das Fehlschlagen eines technischen Details für die gesamte gerade ablaufende Aktion bedeutet. Entsprechend kann sie eine Exception mit einer entsprechenden Aussage werfen, der sie als InnerException die gefangene Exception mitgibt. Das kann übermehrere (Exception)-Stufen erfolgen. Dem Benutzer wird dann erstmal nur äußerste Exception präsentiert und erst auf Nachfrage nacheinander die inneren oder gleich die Innerste.

Das Prinzip ist klar. Aber muß man dazu den Code jeder relevanten Methode in try-catch-Blöcke legen?!? Das erscheint mir irgendwie merkwürdig.

Gerade in den oberen Methoden werden doch jede Menge untergeordnete Methoden aufgerufen. Um jetzt die verschiedenen inneren Exceptions abzufangen, muß ich also den gesamten Code der obersten Methode als Try-Block ausführen?

Umwege erhöhen die Ortskenntnis.

49.485 Beiträge seit 2005
vor 18 Jahren

Hallo Bini,

Aber muß man dazu den Code jeder relevanten Methode in try-catch-Blöcke legen?!?

Die Betonung liegt auf jeder relevanten Methode. Also nur die Methoden, die wirklich neue Information ergänzen sollen, brauchen try-catch.

Um jetzt die verschiedenen inneren Exceptions abzufangen, muß ich also den gesamten Code der obersten Methode als Try-Block ausführen?

Richtig! Ich finde das ganz normal. Was ist daran merkwürdig?

herbivore

195 Beiträge seit 2004
vor 18 Jahren

Original von herbivore
Richtig! Ich finde das ganz normal. Was ist daran merkwürdig?

Ja, weiß auch nicht, ist wahrscheinlich nur Gewöhnungssache 🤔

Mein Schäffe hat sich immer mächtig über einen Kollegen aufgeregt, der überall try-catch-Blöcke hatte - das wäre so unprofessionell 8o Jetzt frag ich mich, wer da eigentlich unprofessionell war 😁

Ich fange Exceptions mitsamt Callstack derzeit einfach ganz zentral ab und speicher mir die an einen für alle User erreichbaren Ort, dort guck ich immer nach und werte die aufgelaufenen Fehler auf.

Geht natürlich nur, weil bei mir alles im Haus verbleibt.

Umwege erhöhen die Ortskenntnis.

49.485 Beiträge seit 2005
vor 18 Jahren

Hallo Bini,

wenn man um jede einzele Anweisung ein try-catch bastelt und in allen catch-Handlern dasselbe macht, hat man sicher was nicht verstanden und das ist dann umprofessionell. Aber try-catch da wo es nötig ist - und um neue Informationen zur Exception hinzuzufügen, ist es nötig - ist durchaus professionell.

herbivore

B
50 Beiträge seit 2005
vor 18 Jahren

Eventuell wäre es von Vorteil hiermal ein paar gute Tutorials zu diesem Thema zu posten. Ich selber kenne jetzt keines das genau auf dieses Problem eingeht.

Schönen Abend noch
Bakunin