Ich schreibe gerade eine Server-Basis-Klasse, von der dann jede andere Serverklasse abgeleitet werden soll - deswegen ist die Server-Basis-Klasse auch abstrakt.
Dabei weiß ich nun nicht, ob ich, damit der Code "weiter oben" beim Aufrufer sauberer wird - man vermeidet das gecatche -, Exceptions direkt beim Auftreten behandeln oder sie lieber weitergeben soll, damit der Aufrufer seine eigene Fehler-Nachricht ausgeben kann.
Beispiel des direkten Behandelns:
Der Vorteil hierbei ist, dass beim Aufrufer jetzt alles sauber ist. Dafür aber wird er immer nur bei Fehlern "Die Verbindung zum Client konnte nicht angenommen werden." lesen können, nicht aber seine eigene Fehler-Meldung oder vielleicht sogar Behandlung.
Beispiel des Weitergebens:
Andererseits hat diese Variante den Vorteil, dass ich die Behandlung beim Aufrufer anpassen und eine andere Fehler-Meldung ausgeben kann, aber sie verschleiert den Code extrem.
Sollte ich die Exceptions lieber weitergeben oder sofort behandeln?
Dabei weiß ich nun nicht, ob ich, damit der Code "weiter oben" beim Aufrufer sauberer wird - man vermeidet das gecatche -, Exceptions direkt beim Auftreten behandeln oder sie lieber weitergeben soll, damit der Aufrufer seine eigene Fehler-Nachricht ausgeben kann.
Beispiel des direkten Behandelns:
protected void waitForClientHavingConnected()
{
try
{
client = server.accept();
}
catch (IOException e)
{
System.out.println("Die Verbindung zum Client konnte nicht angenommen werden.");
e.printStackTrace();
}
clientHasConnected = true;
}
Der Vorteil hierbei ist, dass beim Aufrufer jetzt alles sauber ist. Dafür aber wird er immer nur bei Fehlern "Die Verbindung zum Client konnte nicht angenommen werden." lesen können, nicht aber seine eigene Fehler-Meldung oder vielleicht sogar Behandlung.
Beispiel des Weitergebens:
protected void waitForClientHavingConnected() throws IOException
{
client = server.accept();
clientHasConnected = true;
}
Andererseits hat diese Variante den Vorteil, dass ich die Behandlung beim Aufrufer anpassen und eine andere Fehler-Meldung ausgeben kann, aber sie verschleiert den Code extrem.
Sollte ich die Exceptions lieber weitergeben oder sofort behandeln?
|
41 |
4 Antworten
Also eine feste Regel gibt es nicht, aber eine "Best-Practice": Das Deklarieren von Exceptions im Methodenkopf führt dazu, dass auch aufrufende Methoden die Exceptions weiterdeklarieren. Das resultiert nicht nur in einer gewissen Unübersichtlichkeit (steigt mit Exceptionanzahl), sondern insbesondere auch darin, dass bei Codeänderung die Signaturen aller aufrufenden Methode geändert werden müssen.
Die Lösung sind Runtime-Exceptions, die nicht deklariert werden müssen. Natürlich sollten sie sowohl in dem Methodenkommentar ausführlich dokumentiert werden, als auch mit einer sinnvollen Error-Message versehen sein, sodass ein Aufrufer, der sonst keine Ahnung vom System hat, eine Idee bekommt, was schiefgelaufen ist und wie er das gelöst bekommt.
Die Lösung sind Runtime-Exceptions, die nicht deklariert werden müssen. Natürlich sollten sie sowohl in dem Methodenkommentar ausführlich dokumentiert werden, als auch mit einer sinnvollen Error-Message versehen sein, sodass ein Aufrufer, der sonst keine Ahnung vom System hat, eine Idee bekommt, was schiefgelaufen ist und wie er das gelöst bekommt.
|
278 ● 6 |
Du kannst aber auch ein out Parameter benutzen, die Behandlung dabei intern halten, die Nachrichten aber weiterleiten, z.B.:
Der Aufruf muss dann so aussehen:
Eine andere Variante ware ein Re-Throw. Behandlung intern wie oben, am Ende aber:
Hoffe, es hilft.
protected void waitForClientHavingConnected(string outMsg)
{
try
{
client = server.accept();
outMsg = "Alles super.";
}
catch (IOException e)
{
outMsg = "Die Verbindung zum Client konnte nicht angenommen werden.";
// weitere Behandlung hier...
}
clientHasConnected = true;
}
Der Aufruf muss dann so aussehen:
string outMsg;
waitForClientHavingConnected(out outMsg)
Eine andere Variante ware ein Re-Throw. Behandlung intern wie oben, am Ende aber:
throw new Exception("Die Verbindung zum Client konnte nicht angenommen werden.");Hoffe, es hilft.
|
11 |
Also meiner Meinung, solltest du jede Exception weitergeben. Du kannst dir natürlich überlegen, ob es Sinn die Exceptions, die geworfen werden in eine eigene Exception-Klasse zu packen.
Warum nun immer werfen?! Grundsätzlich solltest du davon ausgehen, dass die Klassen, die du schreibst wiederverwendest. Nun kann es natürlich sein dass Projekt 1 mit der Exception nichts anfangen kann und die Verarbeitung abbricht. Projekt 2 jedoch schon (baut die Connection neu auf). Da solltest du jetzt auch die Problematik erkennen, wenn du die Exception intern innerhlab der Klasse verarbeitest. Dann hast du bei einer Neuverwendung nämlich keinerleit Einfluss mehr auf das Exception-Handling und musst die Klasse anpassen, was man in der Regel vermeiden sollte.
Um es kurz zusammenzufassen. Ich würde Exceptions entweder so lange wie mgölcih weitergeben. Und sie erst an der Stelle auffangen, wo ich mir sicher sein kann, dass ich die Informationen aus der Exception verarbeiten kann.
Warum nun immer werfen?! Grundsätzlich solltest du davon ausgehen, dass die Klassen, die du schreibst wiederverwendest. Nun kann es natürlich sein dass Projekt 1 mit der Exception nichts anfangen kann und die Verarbeitung abbricht. Projekt 2 jedoch schon (baut die Connection neu auf). Da solltest du jetzt auch die Problematik erkennen, wenn du die Exception intern innerhlab der Klasse verarbeitest. Dann hast du bei einer Neuverwendung nämlich keinerleit Einfluss mehr auf das Exception-Handling und musst die Klasse anpassen, was man in der Regel vermeiden sollte.
Um es kurz zusammenzufassen. Ich würde Exceptions entweder so lange wie mgölcih weitergeben. Und sie erst an der Stelle auffangen, wo ich mir sicher sein kann, dass ich die Informationen aus der Exception verarbeiten kann.
|
11 |
