Hallo,
ich habe mit Qt einen Server(Konsolenanwendung) und einen Client(Gui-Anwendung) programmiert. Jetzt möchte ich ein Exception Handling realisieren.
Die Kommunikation läuft über xml. Es gibt eine Klasse Anfrage und Antwort.
Der Client schickt eine Anfrage an den Server. Der Server empfängt die Anfrage und führt das jeweilige Kommando aus und schickt dann eine Antwort zurück.
Anfrage und Antwort haben die gleiche Vaterklasse.
Ich denke mir, dass ich für das Exception Handling jetzt nur mehr eine Klasse brauche, die auch eine Kindklasse ist, wie meine 2 anderen Klassen.
Wenn während des Kommandos ein Fehler auftritt, werfe ich einfach ein Objekt dieser Klasse mit einer entsprechenden Fehlermeldung und schicke in catch-Zweig anstatt einer Antwort eine Exception zurück. Der Client kann dann auf die Fehlermeldung reagieren.
Ist das so korrekt?
server client exceptionhandling
Re: server client exceptionhandling
Generell wuerde es so gehen ... aber design !?
Ich kenn den rest vom code ned ... aber ich vermute das die vererbung hier ueberfluessig ist ...
Wenn Du exceptions faengst, die du nicht selber wirfst ... dann bekommst eh schon ne fertige klasse / Typ als Exceptiontyp. Den kannst auch ned beeinflussen.
Und warum willst du selber exceptions werfen ? Kannst doch stattdessen selber gleich die entsprechende Fehlerbehandlung anwerfen ...
Exceptions sind gut und schoen und nuetzlich. Aber sollten auch ned uebers knie gebrochen werden.
Generell kommt man auch ohne aus. Aber dann werden Schnittstellen oft aufgeblaeht und unleserlich.
Das ist Imho auch ihr Hauptanwendungsfall .... Saubere Schnittstellen ermoeglichen ohne darin zig haken fuer das Fehlerhandling implementieren zu muessen.
Daher lohnt es sich fast nur, wenn man ausgiebig mit statischen libs / templates hantiert.
(dlls und exceptions sind eh ... problematisch, und fuer nicht library code sind schnittstellen meist nicht so dominant, da kann man das fehlerhandling ruhig "klassisch" (also c style) mit durchschleifen) Aber da isses echt auch sehr Geschmackssache.
Ciao ...
Wuerde ich schon mal in frage stellen, das das gues Design ist ...Anfrage und Antwort haben die gleiche Vaterklasse.
Ich kenn den rest vom code ned ... aber ich vermute das die vererbung hier ueberfluessig ist ...
Nein, du brauchst nich mal eine Klasse. Und erst recht keine vererbte ...Ich denke mir, dass ich für das Exception Handling jetzt nur mehr eine Klasse brauche, die auch eine Kindklasse ist, wie meine 2 anderen Klassen.
Wenn Du exceptions faengst, die du nicht selber wirfst ... dann bekommst eh schon ne fertige klasse / Typ als Exceptiontyp. Den kannst auch ned beeinflussen.
Und warum willst du selber exceptions werfen ? Kannst doch stattdessen selber gleich die entsprechende Fehlerbehandlung anwerfen ...
Exceptions sind gut und schoen und nuetzlich. Aber sollten auch ned uebers knie gebrochen werden.
Generell kommt man auch ohne aus. Aber dann werden Schnittstellen oft aufgeblaeht und unleserlich.
Das ist Imho auch ihr Hauptanwendungsfall .... Saubere Schnittstellen ermoeglichen ohne darin zig haken fuer das Fehlerhandling implementieren zu muessen.
Daher lohnt es sich fast nur, wenn man ausgiebig mit statischen libs / templates hantiert.
(dlls und exceptions sind eh ... problematisch, und fuer nicht library code sind schnittstellen meist nicht so dominant, da kann man das fehlerhandling ruhig "klassisch" (also c style) mit durchschleifen) Aber da isses echt auch sehr Geschmackssache.
Ciao ...