Hallo!
Wenn ich eine Exception im Konstruktor (einer Klasse) habe, muss ich diese Exception ja auch in der Main über ein try catch block abfangen.
Beispiel:
public Coordinate(int x, int y) throws Exception{
if (x
hallo
zunächst einmal: mit pre-tag schaut der code leichter lesbar aus!
Coordinate c1;
try {
new Coordinate(-2, 4);
} catch (Exception e) {
}
Mein Problem ist nun, dass ich die Klasseninstanz c1 nicht
mehr verwenden kann, da es ja nur für die Klammern im
try-catch block initialisiert wurde!
Gibt’s da eine andere Möglichkeit? Tipps Tricks? Ich bin für
alles dankbar!
???
was ist eine klasseninstanz?? c1 ist eine variable vom typ „Coordinate“. in deinem programm ist diese variable nicht initialisiert, nachdem der try-catch-block beendet ist, weil der konstruktor fehlschlägt und es daher keine instanz der klasse Coordinate gibt. zusätzlich hast du im obigen beispiel vergessen, die instanz der variable zuzuweisen - hätte also sowieso nie funktioniert.
lesezugriffe auf die variable c1 sind daher nicht möglich, weil die variable nie befüllt wurde und daher deren inhalt undefiniert ist.
was z.b. geht:
Coordinate c1 = null;
try {
c1 = new Coordinate(-2,4);
} catch (Exception e) {
// hier sollte irgendwas kommen, sonst suchst du dich bei fehlern zum deppen
}
if (c1 != null) {
...
}
soweit alles klar?
lg
erwin
Hallo,
ich vermute, dass du das gemeint hast:
Coordinate c1;
try {
c1 = new Coordinate(-2, 4);
} catch (Exception e) {
// Exceptionbehandlung
}
Mein Problem ist nun, dass ich die Klasseninstanz c1 nicht
mehr verwenden kann, da es ja nur für die Klammern im
try-catch block initialisiert wurde!
Ja, und? Es gab ein Problem beim Konstruieren der Coordinate-Instanz; wenn du diesen Fehlerfall irgendwie beheben kannst (indem du andere Koordinatenwerte verwendest), dann mach das. Falls nicht, kannst du vermutlich nicht sinnvoll weiterarbeiten, wie du schon festgestellt hast, und solltest eine Exception werfen (oder das Programm beenden oder …).
Viele Grüße,
Andreas
du kannst das ganze einfach umgehen
nehme einen Konstruktor ohne Parameter
und benutze Getter/Setter -Methoden um die X,Y-Koordinaten zu setzen
wenn ein falscher Wert per Setter kommt, lässt sich das ganze mit einer einfachen isKoordinate() (return true oder false) prüfen ob der Wert richtig gesetzt wurde.
also brauchst du
Instanzvariablen:
int x
int y
boolean xOk
boolean yOk
Wenn z.B. X gesetzt wird und das Setzen erfolgreich (IF-Konstrukt) ist wird die xOk Variable auf true gesetzt (default ist false)
Exception als If-Konstrukte oder Validierungen von Parametern zu benutzen ist kein guter Programmierstil.
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Hallo!
wenn ein falscher Wert per Setter kommt, lässt sich das ganze
mit einer einfachen isKoordinate() (return true oder false)
Nein, ein solches Vorgehen verbietet sich. Eine Objekt, einmal erzeugt, muss halten, was der Klassenname verspricht. Eine Instanz von Coordinate muss gültige Koordinaten enthalten, eine Instanz der Klasse Color muss eine gültige Farbe repräsentieren, sonst hätten die Instanzen keine Daseinsberechtigung.
Gruß, Jan
Da hast du vollkommen recht.
Aber…
Daten die in ein System aufgenommen werden, müssen dort validiert werden, wo sie entstehen. In Beispiel dieses Artikelersteller ist es aber nicht der Fall, sonst würde seine Coordinate nicht auch falsche Parameter bekommen können…
Deshalb muss man von deiner Aussage bzw. Das try-catch Zeug des Artikelerstellers abrücken und meinen Vorschlag benutzen. Die beste Lösung wäre aber:
- ordentlich validieren/korrigieren der X,Y Werte
- das try-catch benutzen für „richtige“ Ausnahmen, das bedeutet: Ausnahmen die entstehen können außerhalb der Validierungen bzw. die nicht durch Validierung abgefangen werden können.
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Hallo!
Deshalb muss man von deiner Aussage bzw. Das try-catch Zeug
des Artikelerstellers abrücken und meinen Vorschlag benutzen.
Von mir stammt keine Aussage zum try, ich habe mich nur zu Deinem Vorschlag geäußert, den ich wirklich für „verboten“ halte. Eine Koordinate, die man erstmal fragen muss, ob sie wirklich eine Koordinate ist, geht meines Erachtens ganz entschieden nicht.
Die beste Lösung wäre aber:
- ordentlich validieren/korrigieren der X,Y Werte
Ja. Unbedingt!
- das try-catch benutzen für „richtige“ Ausnahmen, das
bedeutet: Ausnahmen die entstehen können außerhalb der
Validierungen bzw. die nicht durch Validierung abgefangen
werden können.
Ich würd’ das nicht so streng sehen. Es könnte sein, dass die Validierung recht komplex ist und nur sinnvoll in der Klasse möglich ist. Der Weg über eine Exception wäre meines Erachtens ok. Hier fand ich ein Beispiel: http://openbook.galileocomputing.de/java2/kap_07.htm… „Ausnahme verhindert Instanz-Anlage“.
Ich weiß natürlich nichts von Lukas’ Anforderungen an die Koordinaten-Klasse, aber bei mir gäbe es überhaupt keine Validierung in der Klasse. Eine universelle Koordinaten-Klasse darf durchaus auch negative Werte haben. Wenn die Anwendung, die die Koordinaten-Klasse verwendet, da andere Anforderungen hat, muss das eben die Anwendung sicherstellen vor Erzeugen der Koordinaten-Objekte. Also im Prinzip dein Punkt 1.
Jan
Ich weiß natürlich nichts von Lukas’ Anforderungen an die
Koordinaten-Klasse, aber bei mir gäbe es überhaupt
keine Validierung in der Klasse. Eine universelle
Koordinaten-Klasse darf durchaus auch negative Werte haben.
Wenn die Anwendung, die die Koordinaten-Klasse verwendet, da
andere Anforderungen hat, muss das eben die Anwendung
sicherstellen vor Erzeugen der
Koordinaten-Objekte. Also im Prinzip dein Punkt 1.Jan
genau mein reden, diese Klasse ist für die Datenhaltung/Repräsentation zuständig und braucht entsprechend keine Validierung, damit eine throw blabla auch nicht denn eine „richtige“ Exception kann hier nicht auftreten… Das ist was ich meine try-catch bzw. throws … nur für „richtige“ Ausnahmen benutzen und nicht für Kontrollstrukturen. Das steht auch in diesem Artikel den von dir.
http://openbook.galileocomputing.de/java2/kap_07.htm…
das meine Lösung verboten gehört stimmt, aber harte Programme brauchen harte Methoden *rofl*
nee mal ernsthaft, das war nur eine Lösung aus der Not heraus, ohne das er extreme Modifikationen an seinem Programm vornehmen muss, darüber ob es elegant gelöst ist brauchen wir uns nicht streiten. Es ist mir bewusst das diese Lösung *hüstel* nicht perfekt ist 
Denn die richtige Lösung würde eine grundlegende Änderung seines Programmes evtl. mit sich bringen…