Exceptions

[Reap]

Hallo....ich hab ein paar generelle Fragen zu Exceptions....und zwar...ist in dem Code aus dem Skript nicht ein Fehler? Müsste da nicht statt NullPointerexception e.....SmallerAHalfException e stehen?

Code aus dem Skript:

c
lass SmallerAHalfException extends Exception {
      public SmallerAHalfException() { super(); }
      public SmallerAHalfException(String s) { super(s); }
}
class ThrowRandom {
     public static void main(String args []) {
       for (int i = 1; i <= 10 ; i++) {
         double d;
         try {
            d = java.lang.Math.random();
            System.out.print("Die " + i + ". Zufallszahl ist ");
            if (d < 0.5)
                throw new SmallerAHalfException();
            System.out.println(d);
         } catch ([b] NullPointerException e [/b]) {
            System.out.println("kleiner als 0.5");
            i--;
         }
       }
}
}

In unserem Skript steht dass wenn man Exceptions für Methoden machen will dann müssen sie so ausschauen:

class test{
....
  public void methode() throws exception(){

     if(irgendwas verbotenes){
         throw new exception();
     }
    ....
  }
}

Dass kapier ich auch noch.....aber warum wird dann noch dass gemacht:

Wenn ich Methode in einer Testklasse aufrufe:

....
 test e = new test();
try{
   e.methode();
}catch(exception){
  System.out.println("Du hast was verbotenes gemacht");
}
...

Warum macht man das? Ich hab doch die Exception schon geworfen in der Methode?
Wenn ich das try{...}catch(..){...} weglasse wird mir trotzdem die Exception geworfen....was hat das also für einen Sinn??????
Oder muss ich das immer so machen wenn ich eine Methode testen will in der ich eine Exception eingebaut habe??


mfg,
Reaper

 

[SlaterB]

sieht stark danach aus als wenn da SmallerAHalfException e stehen sollte, ja,

deine zweite Frage ist etwas unverständlich,
Exception-Handling besteht doch immer aus zwei Teilen:
eine Operation wirft die Exception (throws), und irgendwo weiter oben in der Aufrufskette wird sie dann mit try/ catch abgefangen,
das heißt wenn ein Fehler auftritt wird die aktuelle Berechnung abgebrochen bis zu einem definieren Punkt weiter oben (dem catch) von wo aus es normal weiter geht,

alles gut erkennbar im obigen Beispiel mit der SmallerAHalfException, irgendwo wird geworfen und woanders aufgefangen, so wie ein Netz beim Zirkus

> Ich hab doch die Exception schon geworfen in der Methode?

das klingt so als wenn du glaubst dass im atch selber noch eine weitere Exception geworfen wird,
dem ist aber nicht so, im catch wird die alte aufgefangen,

das eine Exception auftritt ist übrigends gar nicht mal so sehr vorgesehen, das ist nur eine Absicherung für den Fehlerfall.

bevor ich weiter rumlabere: was genau ist jetzt dein Verständisproblem dabei?

 

[Guest]

Du wirst damit benachrichtig, dass da etwas schief gehen kann und auch gezwungen, die mögliche Ausnahme zu behandeln (checked exception). Wie diese Behandlung von dir implementiert wird, ist deine sache. Wenn du es nicht machst (leere Implementierung), dann bist du selber schuld, wenn das Programm stirbt. Du wurdes informiert, dass es schief gehen kann. Und das ist der Vorteil des Exception-Mechanismus. Eine mögliche Ausnahme (Gefahr) bleibt nicht unbemerkt!!! Der Compiler sagt es dir klip und klar. Du musst nur passend handeln.

 

[Reap]

Hallo...danke eure Antworten haben mir schon weitergeholfen...

Die 2te Frage hab ich gestellt weil ich bisher immer nur die IllegalArgumentException() in meinen Programmen verwendet habe. Dass ist ja eine vorgegebene Exception.

Hierbei hab ich z.b. folgendes Programm geschrieben (in Eclipse)

class test{
....
  public void methode(int a) throws IllegalArgumentException(){

     if(irgendwas verbotenes bei a){
         throw new IllegalArgumentException("Die Eingabe ist falsch.");
     }
    ....
  }
}

Wenn ich das Ganze dann in einer Testklasse aufgerufen habe hat mir der Compiler auch wirklich die Benachrichtigung
"Die Eingabe ist falsch" hingeschrieben ohne dass ich die Exception aber aufgefangen habe.....also muss ich die Methode normalerweiße immer auffangen oder verhält es sich bei diesen vordefinierten Exceptions wieder anders?

Was überprüft eigentliche eine NullPointerException()?
Ob ich z.b. auf ein null Objekt zugreifen will also enthaltene Daten im Objekt abfragen will die eigentlich gar nicht vorhanden sind?

mfg,
Reaper

 

[SlaterB]

natürlich ist es meist möglich eine Exception nicht abzufangen und zum Programmabbruch führen zu lassen,
in der Konsole steht dann hoffentlich die Fehlermeldung, richtig,

allerdings ist es meist nicht akzeptabel mitten in der Ausführung ein Programm komplett zu verlassen,
stattdessen soll manchmal einfach an eine andere Stelle gesprungen werden von wo aus eine klare Fehlerbehandlung möglich ist
(siehe dein Beispiel ganz oben, bei einer Zahl < 0.5 soll nicht das ganze Programm verlassen werden, stattdessen reiche eine Fehlerausgabe und es geht normal weiter)

--------------


manche Exceptions wie NullPointerException müssen nicht aufgefangen werden, da wäre man ja überall im Programm beschäftigt,
andere dagegen schon, um Kompilermeckereien zu umgehen hilft da nur ein try/ catch oder eine throws-Angabe im Operationskopf um die Exception an die nächsthöhere Stelle weiterzuleiten,

eine NullPointerException gibts bei fehlerhaften Zugriff auf null-Objekte, etwa
Object x = null;
x.hashCode();

andere Zugriffe wie

y = x;
oder
if (x == null) {
}

gehen natürlich auch wenn eine Variable null ist

---------

langsam wirds hier aber ne Aufzählung von Kapiteln aus Lehrbücher, lies doch erstmal die

 

[Reap]

Aha...langsam begreif ichs....hab mal selber ein bißl ausprobiert und es stimmt tatsächlich was du gesagt hast....

Bsp.: Ich hab mal eine Klasse Graph für eine UE erstellt....

........
       Graph graph3 = new Graph(7);
       Graph graph2 = null;
        try{
           graph2.getAdjacencyMatrix();
        }catch(NullPointerException e){
        	 System.out.println("You can't access on a null object.");
        }
             
        try{
           graph3.insertVertex(null);
        }catch(IllegalArgumentException e){
        	 System.out.println("A null object is not allowed.");
.........
        }

Jetzt übermittelt man mir die Fehlermeldung ohne dass das Programm explizit abbricht.....aber die Nullpointerrexception habe ich schon explizit auffangen müssen,....nur halt nicht werfen....darum kapiere ich dein
Statement nicht so ganz:

manche Exceptions wie NullPointerException müssen nicht aufgefangen werden, da wäre man ja überall im Programm beschäftigt,

Denn die Nulpointerexception hab ich nicht extra in der Methode geworfen und der Compiler erkennt sie mir trotzdem.
Hingegen die IllegalArgumentException musste ich schon extra werfen ansonsten würde er sie nicht erkennen.

Meinst du statt aufgefangen etwa werfen?

mfg,
Reaper

 

[SlaterB]

NullPointerException werden vom System automatisch geworfen

z.B. bei Ausführung von graph2.getAdjacencyMatrix(); wenn graph2 null ist,
da muss man nicht
if (graph2 == null) {
throw new NullPointerException();
}
schreiben, das wäre ja auch ziemlich aufwendig bei tausenden Zugriffen in einem großen Programm ,
das macht Java selber,

es ist nur noch die Frage ob man an jeder Stelle im Programm wo ein Zugriff stattfindet eine try/ catch zum ABFANGEN
drumherum schreibt, auch das ist natürlich ziemlich blöde und deshalb nicht zwingend erforderlich,
da testet man lieber so und läßt sich überraschen ob irgendwann mal ein Fehler kommt,

------------

IllegalArgumentException ist schon deutlich seltener,
diese wird nicht unbedingt von Java automatisch geworfen, sondern vielleicht in eine Operation direkt reinkodiert
(throw new IllegalArgumentException()),
wenn das der Fall ist, dann hat man sich was dabei überlegt, dann ist das kein Programmierfehler der einfach nur durch Testen gefunden und korrigiert wird,
sondern ein permantenter Programmteil, von dem auszugehen ist, dass er auch im laufenden Betrieb auftreten kann
(z.B. zum Abfangen falscher Benutzereingaben in Formularen, was also erst zur Laufzeit passiert)

diese Fehler und die zugehörigen Exceptions sollten mit try/ catch abgefangen werden,
es ist zwar nicht immer nötig, der Fehler tritt vielleicht nie auf durch bestimmte Konfigurierung, etwa Beschränkung der möglichen Eingaben in das Formular, das kann aber der Compiler nicht erkennen, und verlangt es aber trotzdem in jedem Fall eine Behandlung um ein Vergessen zu verhindern,

eine Alternative wäre die Exception im Programm immer weiterzuleiten

das Grundkonzept dafür ist dass ein Programmteil mit einem bestimmten Fehler nicht umgehen kann und das einem anderen Programmteil signalisiert, in dem es diesen zur Fehlerbehandlung (oder -weiterleitung) ZWINGT

das ist ein schönes höheres Konzept in Java, manchmal nervig, meist nützlich,
eine Programmiersprache könnte auch ganz ohne solche Mechanismen auskommen, sie dienen nur zu einer gewissen Strukturierung

 

[Reap]

Hallo...danke für die Antwort.....ich hätte da jetzt noch eine Frage...und zwar weiß ich nicht so genau was ein Text im Skript sagen will...vielleicht werdet ihr draus schlau:

Skript:
"Exceptions, die gworfen werden können, müssen deklariert werden. (meint der Satz mit deklarieren im Methodenkopf das methode() throws Exception??)

Die in der Methodendefinition deklarierten Exceptions werden auch "checked" Exceptions genannt (im Unterschied zu den nicht explizit deklarierten und com Compiler nicht explizit geprüften Runtime Exceptions). (z.b eine NullPointerException???)

Das heißt: Runtime Exception werden nciht explizit deklariert. Sie können von jeder Methode gworfen werden und werden deshalb auch nciht vom Compiler überprüft (sie bleiben "unchecked"), d.h. Exceptions der Klassen java.lang.Error und java.lang.RunTimeException und deren Unterklassen müssen nicht in der thrwos Deklaration gekennzeichnet werden. (Ein kleines Bsp. was der Satz meint???)

mfg,
Reap

 

[Oni]

Die in der Methodendefinition deklarierten Exceptions werden auch "checked" Exceptions genannt (im Unterschied zu den nicht explizit deklarierten und com Compiler nicht explizit geprüften Runtime Exceptions). (z.b eine NullPointerException???)

Das heißt: Runtime Exception werden nciht explizit deklariert. Sie können von jeder Methode gworfen werden und werden deshalb auch nciht vom Compiler überprüft (sie bleiben "unchecked"), d.h. Exceptions der Klassen java.lang.Error und java.lang.RunTimeException und deren Unterklassen müssen nicht in der thrwos Deklaration gekennzeichnet werden. (Ein kleines Bsp. was der Satz meint???)

mfg,
Reap

NullPoinerException musst man nicht explizit abfangen bzw geworfen werden, weil du sonst immer wenn du ein object benutzen möchtes z.B meinObject.machWas() einen try/catch block drumherum basteln müsstest, weil das objekt ja null sein könnte. der quellcode würde quasi nur aus try/catch bestehen...
man kann sie zwar bei bedarf abfangen, wir aber nicht dazu gezwungen.

Exception der klasse java.lang.Error und unterklassen wie z.B. VirtualMaschineError muss man nicht abfangen, weil man die fehler meist eh nicht korrigieren kann. z.B OutOfMemoryError.

 

[Lim_Dul]

Es 2 (oder 3) Arten von Exceptions:

a) Die Exceptions, die von RuntimeException abgeleitet sind. Diese müssen nicht per throws im Methodenkopf deklariert werden. Sie zeigen Probleme auf, die man meistens bei sauberer Programmierung verhindern kann. Prominentes Beispiel ist die NullPointerException. Wenn man vorher eine Überprüfung auf != null macht, kann man verhindern dass diese Exception geworfen wird. Von daher deuten RuntimeExceptions häufig auf unsauberen Code oder Programmierfehler hin.

b) Exceptions, die von Exception abgeleitet sind. Das sind die sogenannten Checked Exceptions. Wenn eine Methode eine davon wirft, muss sie das im Methodenkopf mittels throws XY deklarieren. Methoden, die diese Methode aufrufen müssen die Exception entweder verarbeiten mittels catch() oder weiterwerfen. Diese Exceptions melden Fehler, wo es meistens nicht in der Macht des Programmieres liegt, das auftreten des Fehlers zu verhindern. Der Programmierer muss aber den Fehler behandeln. Prominentes Beispiel ist die IOException. Wenn man Daten über ein Netzwerk überträgt, kann es durchaus vorkommen, dass die Verbindung zusammenbricht. (Beispielsweise 24h Stunden Disconnect von T-Online). Dann gibt es eine IOException und das Programm sollte sinnvoll darauf reagieren. (Beispielsweise versuchen, die Verbindung wieder aufzubauen oder einen Dialog mit der Meldung öffnen).

c) Die Klassen, die von Error abgeleitet werden. Dies sind zwar keine Exceptions, aber Error ist wie Exception von Throwable abgeleitet und kann sowohl geworfen, als auch gefangen werden. Allerdings deutet ein Error auf einen Fehler hin, wo es außerhalb der Macht des Programmierers liegt, auf den sinnvoll zu reagieren. Beispiel dafür ist der OutOfMemoryError. Wenn der Auftritt, kann man normalerweise nichts mehr machen. Außerdem ist insbesondere dieser Error nicht deterministisch. Mann kann nicht vorhersagen, an welcher Zeile er auftritt. Er kann im Prinzip überall auftreten.