Ausnahmen in Java
Während der Auswertung des Ausdrucks »v = f()« könnte es sich herausstellen, daß der Wert des Teilausdrucks »f()« nicht ermittelt werden kann. Dann kann die Auswertung durch eine Ausnahme abgebrochen werden, die bei der Auswertung des Teilausdrucks »f()« „geworfen“ wird. Durch solch einen Wurf wird die Auswertung der Zuweisung »v = f()« abgebrochen, und der Wert von »v« wird dann nicht verändert.
Der Ausdruck »java.lang.Integer.parseInt( "0" )« in dem folgenden Programm könnte bei einem anderen Argument solch eine Ausnahme werfen. In dem Programm »Throw.java« wird aber noch nichts geworfen.
Main.javapublic final class Main
{ public static void main( final java.lang.String[] args )
{ final int i = java.lang.Integer.parseInt( "0" );
java.lang.System.out.println( "println" );
java.lang.System.out.println( i ); }}Protokollprintln
0- System.out
0
Die Methode »java.lang.Integer.parseInt(java.lang.String)« soll einen Argumenttext (ein Numerale) in eine ganze Zahl wandeln. Dies ist aber nicht immer möglich, etwa wenn der Argumenttext nicht als ganzzahliges Numerale interpretiert werden kann. Dann wäre es irreführend irgendeine Zahl zurückzugeben. Da das Ergebnis vom Typ »int« ist, muß aber eine Zahl zurückgegeben werden. Ist dies nicht möglich soll dies dem Klienten irgendwie signalisiert werden. Das ist dann durch den Wurf einer Ausnahme möglich. Diese Ausnahme ist ein Objekt der Klasse »java.lang.NumberFormatException«.
- »java.lang.Integer.parseInt(java.lang.String)« [Dokumentation]
java.lang
class Integer
public static int parseInt( java.lang.String s )
throws java.lang.NumberFormatException
Parses the string argument as a signed decimal integer.
Parameters: s - a String to be parsed
Returns: the integer value represented by the argument
Throws: if the string is not a parsable integer.
In dem nächsten Programm wird ein Text als Argument des Methodennamens »java.lang.Integer.parseInt« verwendet, der nicht als ganzzahliges Dezimalnumeral interpretierbar ist. Daher wird eine Ausnahme geworfen, die zum Abbruch der Auswertung der Zuweisung und sogar des ganzen Programms führt.
Wenn bei der Auswertung eines Ausdrucks eine Ausnahme geworfen wird, dann werden alle Operationen, die anschließend sonst ausgeführt werden würden übersprungen und es wird auch aus Methoden zurückgesprungen bis das Programm schließlich ganz verlassen wird.
Main.javapublic final class Main
{ public static void main( final java.lang.String[] args )
{ final int i = java.lang.Integer.parseInt( "~" );
java.lang.System.out.println( "println" );
java.lang.System.out.println( i ); }}ProtokollException in thread "main" java.lang.NumberFormatException: For input string: "~"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Integer.parseInt(Integer.java:580)
at java.lang.Integer.parseInt(Integer.java:615)
at Main.main(Main.java:3)
An Stelle der regulären Ausgabe des Wertes der Variablen »i« erscheint lediglich der Bericht über den Wurf. Die letzte Zeile gibt an, daß die Ausnahme in Zeile 3 der Quelldatei »Main.java« geworfen wurde. Die darüberstehenden Zeilen geben die Herkunft dieser Ausnahme genauer an, sind hier aber weniger interessant. Am Ende der ersten Zeile findet man noch eine Information, die mit dieser Ausnahme transportiert wurde und sie näher beschreiben soll. Diese Angabe »For input string: "~"« ist hilfreich, um die Ursache der Ausnahme zu erkennen.
Jedenfalls sieht man auch, daß das Programm keine Zahl ausgibt. Damit ist das Ziel erreicht worden, nicht einfach mit einem möglicherweise falschen Wert weiterzuarbeiten, sondern den normalen Ablauf zu unterbrechen, wenn er nicht mehr sinnvoll ist.
Das „Fangen“ von Würfen
Der Abbruch eines Programms ist allerdings nicht immer gewünscht, besonders wenn dann noch ein für viele (eventuell deutschsprachige) Bediener kaum verständlicher Bericht ausgegeben wird. Ein Programm wird allerdings nur dann auf diese Weise abgebrochen, wenn ein Wurf die Methode »main« verläßt. Um dies zu verhindern, kann er zuvor „gefangen“ werden.
Zum Fangen eines Wurfes kann das Schlüsselwort »try« vor einen Block geschrieben werden.
Direkt hinter diesen Block können dann beliebig viele Fänger geschrieben werden, die Deklarationen von Methoden ähneln.
Wird nun in dem Block hinter »try« eine Ausnahme geworfen, deren Typ ein Untertyp des Typs eines Fängers ist, so wird dieser Fänger aktiviert. Nach der Aktivierung eines Fängers wird der Ablauf des Blocks hinter dem letzten Fänger fortgesetzt, das Programm wird also dann nicht abgebrochen. Man sagt auch, daß man die Ausnahme „gefangen“ habe.
Wenn bei der Auswertung eines Ausdrucks eine Ausnahme geworfen wird, dann werden alle Operationen, die anschließend sonst ausgeführt werden würden übersprungen und es wird auch aus Methoden zurückgesprungen bis die Ausnahme entweder gefangen oder das Programm schließlich ganz verlassen wird.
Main.javapublic final class Main
{ public static void main( final java.lang.String[] args )
{ try
{ final int i = java.lang.Integer.parseInt( "~" );
java.lang.System.out.println( "println 0" );
java.lang.System.out.println( i ); }
catch( final java.lang.NumberFormatException exception )
{ java.lang.System.err.println( "Text ist kein Numerale." ); }
java.lang.System.out.println( "println 1" ); }}ProtokollText ist kein Numerale.
println 1Main.javapublic final class Main
{ public static void main( final java.lang.String[] args )
{ try
{ final int i = java.lang.Integer.parseInt( "0" );
java.lang.System.out.println( "println 0" );
java.lang.System.out.println( i ); }
catch( final java.lang.NumberFormatException exception )
{ java.lang.System.err.println( "Text ist kein Numerale." ); }
java.lang.System.out.println( "println 1" ); }}Protokollprintln 0
0
println 1System.out0
Ausnahmen sind Objekte von Unterklassen der Klasse "java.lang.Exception". Beim Fangen von Ausnahmen kann auch eine geeignete Oberklasse angegeben werden.
Fangen mit einem Obertyp
Das folgende Programm zeigt das Fangen mit dem Typ »java.lang.Exception«, einem Obertyp von »java.lang.NumberFormatException«.
Main.javapublic final class Main
{ public static void main( final java.lang.String[] args )
{ try
{ final int i = java.lang.Integer.parseInt( "~" );
java.lang.System.out.println( "println 0" );
java.lang.System.out.println( i ); }
catch( final java.lang.Exception exception )
{ java.lang.System.err.println( "Text ist kein Numerale." ); }
java.lang.System.out.println( "println 1" ); }}ProtokollText ist kein Numerale.
println 1System.outText ist kein Numerale.
Es ist robuster, immer nur genau die spezielle Ausnahme zu fangen, die man auch erwartet, und keinen Obertyp zu verwenden, weil es bei Verwendung eines Obertyps sein könnte, daß eine unerwartete Ausnahme (deren Typ denselben Obertyp hat) mitgefangen und dann an dieser Stelle falsch behandelt wird.
Der höchste werf- und fangbare Typ ist »java.lang.Throwable«.
Main.javapublic final class Main
{ public static void main( final java.lang.String[] args )
{ try
{ final int i = java.lang.Integer.parseInt( "~" );
java.lang.System.out.println( "println 0" );
java.lang.System.out.println( i ); }
catch( final java.lang.Throwable throwable )
{ java.lang.System.err.println( "Text ist kein Numerale." ); }
java.lang.System.out.println( "println 1" ); }}ProtokollText ist kein Numerale.
println 1System.outText ist kein Numerale.
Obwohl es bequem wäre, grundsätzlich immer alles mit »java.lang.Throwable« zu fangen, wird davon abgeraten, da damit auch Exemplare von »java.lang.Error« gefangen werden, die aber nach herrschender Meinung nur in Ausnahmefällen so pauschal gefangen werden sollten, da es oft besser ist, das Programm abzubrechen, wenn ein solches Exemplar geworfen wurde, weil der Wurf eines java.lang.Error -Exemplars auf eine schwerwiegende Störung hinweist.
Falls es mehrere catch -Klauseln in Frage kommen, so wird innerhalb einer try-Anweisung die erste aktiviert.
“If the run-time type of V is assignment compatible with (§5.2) a catchable exception class of any catch clause of the try statement, then the first (leftmost) such catch clause is selected.”, JLS7, 14.20.1
Verschachtelte Fänger innerhalb einer Methode
Main.javapublic final class Main
{ public static void main( final java.lang.String args[] )
{try
{ java.lang.System.out.println( 1 / args.length );
java.lang.System.out.println( "println 0" ); }catch( final java.lang.ArithmeticException exception )
{ java.lang.System.out.println( exception.toString() ); }
java.lang.System.out.println( "println 1" ); }}Protokolljava.lang.ArithmeticException: / by zero
println 1- Aussprachehinweis
- arithmetic ˌærɪθˈmɛtɪk (die voranstehende Aussprache gilt für das Adjektiv, die Aussprach des Substantivs lautet /əˈrɪθmətɪk/)
Main.javapublic final class Main
{ public static void main( final java.lang.String args[] )
{ try
{ try
{ java.lang.System.out.println( 1 / args.length );
java.lang.System.out.println( "println 0" ); }
catch( final java.lang.ArithmeticException exception )
{ java.lang.System.out.println( "println 1" );
java.lang.System.out.println( exception.toString() ); }}
catch( final java.lang.ArithmeticException exception )
{ java.lang.System.out.println( "gamma" );
java.lang.System.out.println( exception.toString() ); }
java.lang.System.out.println( "println 2" ); }}Protokollprintln 1
java.lang.ArithmeticException: / by zero
println 2
Da die Ausnahme innen schon einmal gefangen wurde, befindet sie sich nicht mehr in der Luft. Sie wird daher nicht außen erneut gefangen.
Main.javapublic final class Main
{ public static void main( final java.lang.String args[] )
{ try
{ try
{ java.lang.System.out.println( 1 / args.length );
java.lang.System.out.println( "println 0" ); }
catch( final java.lang.ArithmeticException exception )
{ java.lang.System.out.println( "println 1" );
java.lang.System.out.println( exception.toString() ); }}
catch( final java.lang.RuntimeException exception )
{ java.lang.System.out.println( "println 2" );
java.lang.System.out.println( exception.toString() ); }
java.lang.System.out.println( "println 3" ); }}Protokollprintln 1
java.lang.ArithmeticException: / by zero
println 3
Da die Ausnahme innen schon einmal gefangen wurde, befindet sie sich nicht mehr in der Luft. Sie wird daher nicht außen erneut gefangen.
Main.javapublic final class Main
{ public static void main( final java.lang.String args[] )
{ try
{ try
{ (( java.io.PrintStream )null ).println( 0 );
java.lang.System.out.println( "println 0" ); }
catch( final java.lang.ArithmeticException exception )
{ java.lang.System.out.println( "println 1" );
java.lang.System.out.println( exception.toString() ); }}
catch( final java.lang.RuntimeException exception )
{ java.lang.System.out.println( "println 2" );
java.lang.System.out.println( exception.toString() ); }}}Protokollprintln 2
java.lang.NullPointerException
Hier wird die Ausnahme nur außen gefangen, da sie erstmals einer Unterklasse angehört.
Main.javapublic final class Main
{public static void other()
{ try
{ (( java.io.PrintStream ) null ).println( 0 );
java.lang.System.out.println( "println 0" ); }
catch( final java.lang.ArithmeticException exception )
{ java.lang.System.out.println( "println 1" );
java.lang.System.out.println( exception.toString() ); }
java.lang.System.out.println( "println 2" ); }public static void between()
{ other();
java.lang.System.out.println( "println 3" ); }public static void main( final java.lang.String args[] )
{ try
{ between();
java.lang.System.out.println( "println 4" ); }
catch( final java.lang.RuntimeException exception )
{ java.lang.System.out.println( "println 5" );
java.lang.System.out.println( exception.toString() ); }
java.lang.System.out.println( "println 6" ); }}Protokollprintln 5
java.lang.NullPointerException
println 6
Dasselbe, aber mit einer Zwischenmethode.
Main.javapublic final class Main
{public static void other( final java.lang.String args[] )
{ try
{ java.lang.System.out.println( 1 / args.length );
java.lang.System.out.println( "println 0" ); }
catch( final java.lang.ArithmeticException exception )
{ java.lang.System.out.println( "println 1" );
java.lang.System.out.println( exception.toString() ); }
java.lang.System.out.println( "println 2" ); }public static void between( final java.lang.String args[] )
{ other( args );
java.lang.System.out.println( "println 3" );}public static void main( final java.lang.String args[] )
{ try
{ between( args );
java.lang.System.out.println( "println 4" ); }
catch( final java.lang.RuntimeException exception )
{ java.lang.System.out.println( "println 5" );
java.lang.System.out.println( exception.toString() ); }
java.lang.System.out.println( "println 6" ); }}Protokollprintln 1
java.lang.ArithmeticException: / by zero
println 2
println 3
println 4
println 6
Dasselbe, aber mit Fang in der innersten Methode.
Das Verstecken von Ausnahmen
Eine Ausnahme wird versteckt, wenn keine Hinweise auf das Auftreten der Ausgabe nach außen gegeben werden, aber die Ausnahme auch nicht in sinnvoller Weise behandelt wird. Es wird oft pauschal als Mangel verdammt, weil es das Finden von Fehlern erschweren kann, aber es gibt auch Fälle, in denen es akzeptabel sein kann.
Main.javapublic final class Main
{ public static void main( final java.lang.String args[] )
{ try
{ java.lang.System.out.println( 1 / args.length );
java.lang.System.out.println( "println 0" ); }
catch( final java.lang.ArithmeticException ignore )
{ }
java.lang.System.out.println( "println 1" ); }}Protokollprintln 1
Die Ariane 5, 1996
Die Ariane 5 (500 Millionen Dollar) explodierte 1996, weil eine Ausnahme (exception ) in einem Programm, welches in der Programmiersprache Ada geschrieben wurde, nicht behandelt wurde und so das ganze Steuerprogramm beendet wurde.
“The reason why the active SRI 2 did not send correct attitude data was that the unit had declared a failure due to a software exception.” – aus dem offiziellen Bericht
Dabei trat der Fehler in einem Programmteil auf, der während des Fluges eigentlich gar nicht benötigt wurde. Der Fehler hätte in diesem Fall schon vermieden werden können, wenn dieser ganze Programmteil in ein pauschales versteckendes Catch eingerahmt worden wäre, obwohl dies manchmal pauschal als schlechter Stil kritisiert wird.
- Pauschales versteckendes Catch
try { something(); }
catch( final java.lang.Throwable ignore ){ }
Die Overflow-Ausnahme einer Variablen wurde nicht gefangen, weil eine Analyse ergeben hatte, daß keine Overflow-Ausnahme bei dieser Variablen auftreten kann und der Programmteil zum Fangen der Ausnahme das Programm anscheinend irgendwie gebremst oder belastet hätte (“not all the conversions were protected because a maximum workload target of 80% had been set for the SRI computer ”). Diese Analyse war auch richtig, und zwar für die Ariane 4. Der Programmteil wurde aber dann auch für die Ariane 5 eingesetzt, anscheinend ohne daß diese Analyse wiederholt wurde.
Wie hätte der Fehler vermieden werden können? In der Dokumentation des Programmteils hätte beschrieben werden müssen, daß dieser Programmteil nur dann eingesetzt werden darf, wenn die Parameter sich in dem Wertebereich befinden, den sie bei der Ariane 4 haben (dies stand auch angeblich irgendwo an einer etwas versteckten Stelle). Bei der Verwendung des Programmteils für die Ariane 5 hätte diese Dokumentation dann gelesen werden müssen. Dann hätte man erkennen können, daß dieser Programteil für die Ariane 5 nicht eingesetzt werden darf.
Das Problem wäre so auch dann nicht aufgetreten, wenn eine Programmiersprache verwendet worden wäre, in der es gar keine Ausnahmen gibt, sondern Fehler über Status-Codes zurückgemeldet werden.
Das Deklarieren von Ausnahmen
Einige Ausnahmen sind sogenannte „kontrollierte Ausnahmen “. Wenn sie in einer Methode nicht gefangen werden, dann muß in der Schnittstelle der Methode deklarierte werden, daß sie von dieser Methode geworfen werden könnten.
Kontrollierte Ausnahmen modellieren Situationen, in denen aus Gründen, die nicht vom Programm zu vertreten sind, die Auswertung eines Ausdrucks nicht das Verhalten hervorrufen konnte, das damit normalerweise beabsichtigt wird. Beispielsweise kann es eine Ausnahme darstellen, wenn eine Auswertung zum Zugriff auf eine Datei die angegebene Datei nicht findet. Solche Ausnahmen müssen dem Programmierer bewußt sein, weswegen ihre Deklaration oder Behandlung vom Übersetzer kontrolliert wird.
- Eine Methode mit einer deklarierten kontrollierten Ausnahmen
public static void example()
throws java.io.FileNotFoundException{ new java.io.FileInputStream( "source" ); }
Wird nun in einer anderen Methode die Methode "example" aufgerufen, so muß die aufrufende Methode ihrerseits die von der Methode "example" deklarierte kontrollierte Ausnahme selber wieder entweder deklarieren oder fangen.
- Eine Methode mit einer aufgefangenen kontrollierten Ausnahme
public static void example1()
{ try
{ example(); }catch( final java.io.FileNotFoundException fileNotFoundException )
{ java.lang.System.err.println( fileNotFoundException ); }}- Eine Methode mit einer deklarierten kontrollierten Ausnahme
public static void example1()
throws java.io.FileNotFoundException{ example(); }
Beim Deklarieren von Ausnahmen kann auch eine geeignete Oberklasse angegeben werden.
Es ist meist schädlich, Ausnahmen nur zu fangen, um den Anforderungen zu genügen, aber keine Information über ihr Auftreten auszugeben. Dies ist nur dann passend, wenn das Auftreten der Ausnahme das Programm nicht an der Erfüllung seiner Hauptaufgaben hindert oder die Ausnahme vom Programm so behandelt werden kann, daß es trotzdem seine Hauptaufgaben erfüllen kann. Ansonsten ist es oft besser die Ausnahmen nicht zu fangen, sondern weiterzuleiten.
Durch die Weiterleitung von Ausnahmen kann allerdings Information über die Implementation nach außen dringen, weil die Ausnahmen Teil der Schnittstelle werden. Dadurch kann es später erschwert werden, die Implementation zu verändern. Um dies zu verhindern, können deklarierte Ausnahmen in spezielle Ausnahmeobjekte verpackt werden, die auch bei einer Änderung der Implementation beibehalten werden können.
Schlafen mit Fangen
Ohne Fangen kann man nicht schlafen!
try{ Thread.sleep( 3000 ); }catch( final java.lang.InterruptedException interruptedException ){}
Nicht vom Übersetzer kontrollierte Ausnahmen
Neben den kontrollierten Ausnahmen gibt es noch Laufzeitausnahmen, die nicht deklariert werden müssen. Diese Ausnahmen sind Unterklassen der Klasse "java.lang.RuntimeException", einer Unterklasse der Klasse "java.lang.Exception".
Jede Auswertung kann Laufzeitausnahmen werfen, ohne daß man im allgemeinen weiß, welche zu erwarten sind. Daher kann ein Programmierer bestimmte Laufzeitausnahmen in der Regel nicht erwarten, sondern nur allgemein erwarten, daß irgendwelche Laufzeitausnahmen auftreten könnten. Deswegen ist es auch weniger naheliegend in untergeordneten Methoden Laufzeitausnahmen zu behandeln, da eine gezielte Behandlung bei Ausnahmen unbekanntem Typs nicht möglich ist. So werden Laufzeitausnahmen eher ignoriert oder nur in übergeordneten Methoden allgemein behandelt.
Eine Laufzeitausnahme kann beispielsweise entstehen, wenn ein Objekt angelegt werden soll und nicht mehr genügend Speicher bereitsteht. Dann kann ein Programm oft kaum noch etwas tun, außer vielleicht einen Reservespeicher freizugeben und das Programm noch möglichst ordnungsgemäß zu beenden.
Eine Laufzeitausnahme kann auch durch Fehlerzustände entstehen, die bei ordentlicher Programmierung vermeidbar sind, wie etwa durch die Verwendung unerlaubter Positionen in Speicherbereichen, unerlaubter Argumentwerte öffentlicher Methoden oder die Dereferenzierung der Nullreferenz. Dann hat es wenig Sinn, eine Behandlung zu programmieren. Statt dessen sollte durch korrekte Programmierung verhindert werden, daß sie überhaupt erst entstehen.
Throwable
|
.----------------'----------------.
| |
Exception Error
|
|
RuntimeException
Ausnahmen und Ressourcen
void muster()
{ Resource r = null;
boolean ok = false;try
{ r = providerOpenResource();
ok = true; }
catch( final Exception exception )
{ applicationAllocationFailure(); }if( ok )try
{ applicationUse( r ); }
catch( final Exception exception )
{ applicationApplicationFailure( exception ); }
finally
{ try
{ r.providerClose(); }
catch( final Exception exception )
{ applicationCloseFailure(); }}}- Aussprachehinweis
- close cloz
Das Werfen
Main.javapublic final class Main
{ public static void main( final java.lang.String[] args )
{ throw new java.lang.RuntimeException();
java.lang.System.out.println( "println 0" ); }}transcriptMain.java:4: error: unreachable statement
java.lang.System.out.println( "println 0" ); }}
^
1 errorMain.javapublic final class Main
{ public static void main( final java.lang.String[] args )
{ if( java.lang.Math.random() >= 0.0 )throw new java.lang.RuntimeException();
java.lang.System.out.println( "println 0" ); }}transcriptException in thread "main" java.lang.RuntimeException
at Main.main(Main.java:3)Main.javapublic final class Main
{ public static void main( final java.lang.String args[] )
{try
{ if( java.lang.Math.random() >= 0.0 )throw new java.lang.RuntimeException();
java.lang.System.out.println( "println 0" ); }
catch( final java.lang.RuntimeException exception )
{ java.lang.System.out.println( "println 1" ); }
java.lang.System.out.println( "println 2" ); }}Protokollprintln 1
println 2
Beispiel für Erweiterung Klassen für werfbare Objekte
Damit ein Objekt geworfen werden kann, muß es »java.lang.Throwable« erweitern. Dies kann durch Erweitern von »java.lang.RuntimeException« sichergestellt werden, da »java.lang.RuntimeException« »java.lang.Throwable« erweitert.
Main.javafinal class SpecialException {}
public final class Main
{ public static void main( final java.lang.String[] args )
{ throw new SpecialException(); }}transcriptMain.java:5: error: incompatible types: SpecialException cannot be converted to Throwable
{ throw new SpecialException(); }}
^
1 errorMain.javafinal class SpecialException extends java.lang.RuntimeException {}
public final class Main
{ public static void main( final java.lang.String[] args )
{ throw new SpecialException(); }}transcriptException in thread "main" SpecialException
at Main.main(Main.java:5)
Beispiel
Main.javapublic final class Main
{ public static void main ( final java.lang.String[] args )
{ double m = 1; char[] buff;
try
{ for( ;; m *= 1.1 )
{ buff = null;
buff = new char[( int )m ]; }}
catch( final java.lang.OutOfMemoryError outOfMemoryError )
{ java.lang.System.out.printf( "%12.0f%n", m / 1.1 ); }}}transcript88592213
»AutoCloseable« und Ressourcen-try
Main.javaclass Ressource implements java.lang.AutoCloseable
{ public void close()
{ java.lang.System.err.println( "I been closed." ); }}public final class Main
{public static void main( final java.lang.String[] args )
{ try( final Ressource ressource = new Ressource() ){} }}transcriptI been closed.
Main.javaclass Ressource implements java.lang.AutoCloseable
{ public void close()
{ java.lang.System.err.println( "I been closed." ); }}public final class Main
{public static int f()
{ try( final Ressource ressource = new Ressource() )
{ return 1; }}public static void main( final java.lang.String[] args )
{ java.lang.System.out.println( f() ); }}transcriptI been closed.
1Main.javapublic final class Main
{public static int f()
{ try( final java.util.Scanner scanner = new java.util.Scanner( "" ))
{ return 1; }
catch( final java.lang.RuntimeException exception )
{} }public static void main( final java.lang.String[] args )
{ java.lang.System.out.println( f() ); }}transcriptMain.java:8: error: missing return statement
{} }
^
1 error
Übungsfrage
Welche Ausgaben sind bei dem folgenden Programm möglich?
Main.javapublic final class Main
{public static int f()
{ if( java.lang.Math.random() > 0.5 )
throw new java.lang.RuntimeException();
return 1; }public static int g()
{ try
{ return f(); }
catch( final java.lang.Exception exception )
{ return 0; }}public static void main( final java.lang.String[] args )
{ java.lang.System.out.println( 2 * g() + g() ); }}
Programme mit Exceptions enthalten eine versteckte Komplexität und können schnell unübersichtlich werden, ohne daß man es merkt! Dadurch können Fehler, die beim Durchlaufen eines „versteckten Ausführungspfades“ entstehen, unentdeckt bleiben.
Übungen
/ Umwandlungsmethode
Schreiben Sie eine Deklaration einer Methode namens »boolean_of«, welche einen Argumentwert vom Typ ›java.lang.String‹ in den Typ ›boolean‹ wandelt. Der Wert der Methode soll «false» für den Argumentwert «"false"» sowie «true» für den Argumentwert «"true"» sein. Bei anderen Argumentwerten soll eine passende Ausnahme geworfen werden.
/ Umwandlungsmethode (1)
Ändern Sie die Lösung der vorigen Aufgabe so ab, daß auch Varianten der Groß- und Kleinschreibung akzeptiert werden. So sollte die Methoden beispielsweise auch für «"tRUe"» das Ergebnis «true» liefern.
- / Rückgabe eines Status
- Deklarieren Sie eine Methode »openSourceOrNull«, die versucht, ein Objekt der Klasse »java.io.FileInputStream« mit dem Argument »"source"« zu konstruieren. Diese Methode kann dem folgenden Beispiel ähneln. Sie soll jedoch keine Ausnahme vom Typ »java.io.FileNotFoundException« werfen, sondern in den Fällen, in denen die Methode »openSourceOrThrow« eine solche Ausnahme werfen würde, eine Nullreferenz als Ergebnis liefern.
- (Diese Aufgabe dient hier nur zur Übung. Sie soll nicht als Empfehlung verstanden werden, Nullreferenzen an Stelle von Ausnahmen zu verwenden.)
openSourceOrThrowpublic static java.io.FileInputStream openSourceOrThrow()
throws java.io.FileNotFoundException{ return new java.io.FileInputStream( "source" ); }
- / Rückgabe eines Wertes
- Die folgende Methode soll den Wert 0 ergeben, falls ihr Argument eine Nullreferenz ist. Schreiben Sie diese so um, daß sich dieses Verhalten nicht ändert, aber kein »try« mehr darin verwendet wird.
- (Diese Aufgabe dient hier nur zur Übung. Sie soll nicht als Empfehlung verstanden werden, Methoden dieser Art zu programmieren.)
openSourceOrThrowpublic static int length( final java.lang.String string )
{ try
{ return string.length(); }catch( final java.lang.NullPointerException nullPointerException )
{ return 0; }}