Script Java
Script Java Script Java
7.4 Exception Handling In einem Programm können also Exceptions explizit mit dem Schlüsselwort throw generiert werden. Andererseits ist es aber auch möglich, im Programm kein einziges throw statement zu verwenden und dennoch mit Exceptions konfrontiert zu werden. Dies ist dann der Fall, wenn eine Methode aufgerufen wird, die in ihrer Signatur ein throws statement deklariert. In einer solchen Situation entsteht eine Exception implizit. Will man eine Exception - sei sie nun explizit oder implizit generiert - sinngemäss behandeln, muss man einerseits ein catch statement zur Verfügung stellen und andererseits diejenigen Anweisungen, welche Exceptions provozieren, in geschweifte Klammern setzen und mit dem Schlüsselwort try bezeichnen. Ein try statement markiert jene Anweisungen, welche den Auswurf einer Exception hervorrufen können. Hierbei garantiert ein try statement, dass eine allfällige Exception in einem geeigneten catch statement gehandhabt wird. Für ein try statement gibt es also immer ein entsprechendes catch statement, welches nach diesem zu finden ist. Abbildung 7-7 demonstriert, wie eine Exception explizit geworfen und am Ort des Methodenaufrufs aufgefangen wird. e method() throws Exception { . . throw new Exception(); . . } . . try { method(); } catch (Exception e) { . . } . . Abbildung 7-7: Illustration Exception Handling Wenden wir uns nun dem Exception Handling im Beispielprogramm zu: Die Methode 192
7.4 Exception Handling public void setTime (String s) throws NumberFormatException { String hString, mString; StringTokenizer tokenizer = new StringTokenizer(s,":"); try { hString = tokenizer.nextToken(); mString = tokenizer.nextToken(); } catch (NoSuchElementException e) { throw new NumberFormatException(); } setTime(Integer.parseInt(hString),Integer.parseInt(mString)); } setzt die Uhrzeit gemäss der Eingabe durch den Benutzer. Hierbei lässt sie aber nur eine korrekte Zeitangabe zu. In der Methodenschnittstelle wird deklariert, dass die Methode setTime() eine Instanz der Klasse NumberFormatException werfen kann. NumberFormatException ist eine Unterklasse der Klasse IllegalArgumentException, die ihrerseits wiederum eine Unterklasse von RuntimeException ist. Sie signalisiert, dass der Versuch einen String zu einem Integer-Datentyp zu konvertieren missglückt ist, da der String nicht das erforderte Format aufweist. Ein Blick in den Methodenrumpf verrät, dass eine Instanz der Klasse NumberFormatException explizit geworfen wird: throw new NumberFormatException(); Da sich diese Anweisung aber innerhalb eines catch statement befindet, muss ihre Durchführung vom Auftreten einer weiteren Exception abhängig sein. Diese Exception muss gemäss Deklaration vom Typ NoSuchElementException sein. Es fragt sich nun, welche Anweisungen den Auswurf einer Instanz von NoSuchElementException provoziert haben. Diese müssen durch das Schlüsselwort try gekennzeichnet sein und entweder explizit oder implizit eine NoSuchElementException werfen. Oberhalb des catch statement ist auch das erwartete try statement zu finden; es kapselt in sich die Anweisungen try { hString = tokenizer.nextToken(); mString = tokenizer.nextToken(); } Da in diesen Anweisungen kein throw statement vorhanden ist, muss die NoSuchElementException implizit generiert werden, es muss also eine Methode aufgerufen werden, welche ihrerseits eine solche Exception generiert. Die in der Klasse StringTokenizer (siehe Abschnitt 7.4.1.1) deklarierte Methode nextToken() wirft eine Instanz der Klasse NoSuchElementException, wenn 193
- Seite 141 und 142: 5.1 ActionEvent und ActionListener
- Seite 143 und 144: 5.1 ActionEvent und ActionListener
- Seite 145 und 146: 5.2 Zusammenfassung ♦ Damit eintr
- Seite 147 und 148: 6.1 Instanzmethode versus Klassenme
- Seite 149 und 150: 6.1 Instanzmethode versus Klassenme
- Seite 151 und 152: 6.1 Instanzmethode versus Klassenme
- Seite 153 und 154: 6.1 Instanzmethode versus Klassenme
- Seite 155 und 156: 6.2 Visiblity Modifiers ClassMethod
- Seite 157 und 158: 6.2 Visiblity Modifiers } subjectLi
- Seite 159 und 160: 6.2 Visiblity Modifiers Eine Instan
- Seite 161 und 162: 6.2 Visiblity Modifiers 6.2.2 Synta
- Seite 163 und 164: 7.1 Calendar 7Method Overloading Ar
- Seite 165 und 166: 7.1 Calendar } text.requestFocus();
- Seite 167 und 168: 7.1 Calendar In den restlichen Zeil
- Seite 169 und 170: 7.1 Calendar Die Klassenmethode get
- Seite 171 und 172: 7.2 Graphics public void setTime(in
- Seite 173 und 174: 7.2 Graphics in der Methode paint()
- Seite 175 und 176: 7.2 Graphics zunehmen, muss man als
- Seite 177 und 178: 7.3 Arrays g.drawLine(x+r,y+r, x+r+
- Seite 179 und 180: 7.3 Arrays } } "one","two","three",
- Seite 181 und 182: 7.3 Arrays message.setText(time.toF
- Seite 183 und 184: 7.3 Arrays if (minutes%15==0) gepr
- Seite 185 und 186: 7.4 Exception Handling ArrayAcess I
- Seite 187 und 188: 7.4 Exception Handling Abbildung 7-
- Seite 189 und 190: 7.4 Exception Handling Handling Ins
- Seite 191: 7.4 Exception Handling Wenn es im P
- Seite 195 und 196: 7.4 Exception Handling Schlüsselwo
- Seite 197 und 198: 7.5 Zusammenfassung ExceptionHandli
- Seite 199 und 200: 8.1 Abstrakte Methoden und Klassen
- Seite 201 und 202: 8.1 Abstrakte Methoden und Klassen
- Seite 203 und 204: 8.1 Abstrakte Methoden und Klassen
- Seite 205 und 206: 8.1 Abstrakte Methoden und Klassen
- Seite 207 und 208: 8.1 Abstrakte Methoden und Klassen
- Seite 209 und 210: 8.1 Abstrakte Methoden und Klassen
- Seite 211 und 212: 8.1 Abstrakte Methoden und Klassen
- Seite 213 und 214: 9.1 Interfaces und Adapter-Klassen
- Seite 215 und 216: 9.1 Interfaces und Adapter-Klassen
- Seite 217 und 218: 9.1 Interfaces und Adapter-Klassen
- Seite 219 und 220: 9.1 Interfaces und Adapter-Klassen
- Seite 221 und 222: 9.2 Zusammenfassung Muss man zwecks
- Seite 223 und 224: 10.1 Zweidimensionaler Array 10Arra
- Seite 225 und 226: 10.1 Zweidimensionaler Array public
- Seite 227 und 228: 10.1 Zweidimensionaler Array new Ti
- Seite 229 und 230: 11.1 Turtle-Geometrie } (int)Math.r
- Seite 231 und 232: 11.2 Vererbung forward() right() Ab
- Seite 233 und 234: 11.3 Rekursion Abbildung 11-3: Turt
- Seite 235 und 236: 11.3 Rekursion } setSize(400,400);
- Seite 237 und 238: 11.3 Rekursion public void tree(int
- Seite 239 und 240: 11.4 Stack import java.awt.event.*;
- Seite 241 und 242: 11.4 Stack public NumCheckbox(int n
7.4 Exception Handling<br />
In einem Programm können also Exceptions explizit mit dem Schlüsselwort throw<br />
generiert werden. Andererseits ist es aber auch möglich, im Programm kein einziges throw<br />
statement zu verwenden und dennoch mit Exceptions konfrontiert zu werden. Dies ist dann<br />
der Fall, wenn eine Methode aufgerufen wird, die in ihrer Signatur ein throws statement<br />
deklariert. In einer solchen Situation entsteht eine Exception implizit.<br />
Will man eine Exception - sei sie nun explizit oder implizit generiert - sinngemäss<br />
behandeln, muss man einerseits ein catch statement zur Verfügung stellen und andererseits<br />
diejenigen Anweisungen, welche Exceptions provozieren, in geschweifte Klammern setzen<br />
und mit dem Schlüsselwort try bezeichnen. Ein try statement markiert jene<br />
Anweisungen, welche den Auswurf einer Exception hervorrufen können. Hierbei garantiert<br />
ein try statement, dass eine allfällige Exception in einem geeigneten catch statement<br />
gehandhabt wird. Für ein try statement gibt es also immer ein entsprechendes catch<br />
statement, welches nach diesem zu finden ist.<br />
Abbildung 7-7 demonstriert, wie eine Exception explizit geworfen und am Ort des<br />
Methodenaufrufs aufgefangen wird.<br />
e<br />
method() throws Exception {<br />
.<br />
.<br />
throw new Exception();<br />
.<br />
.<br />
}<br />
.<br />
.<br />
try {<br />
method();<br />
}<br />
catch (Exception e) {<br />
.<br />
.<br />
}<br />
.<br />
.<br />
Abbildung 7-7: Illustration Exception Handling<br />
Wenden wir uns nun dem Exception Handling im Beispielprogramm zu:<br />
Die Methode<br />
192