Rethrowing

Java-Forum Java-Grundlagen
1

Was sind notwendigen zusätzlichen Anweisungen , wenn die FileNotFoundException in
der Methode methode1() noch einmal geworfen werden soll.Rethrowing

public class Aufgabe
{
    public static void main(String[] arg)
    {
        Aufgabe aufgabe = new Aufgabe();
        aufgabe.methode1();
    }

    public void methode1()
    {
        try (RandomAccessFile rf = new RandomAccessFile("a.txt", "r")) 
        {
            int zahl = rf.readInt();
        }
        catch (FileNotFoundException fnfe) 
        {
            System.out.format("Datei nicht gefunden.
");
        }
        catch (IOException ioe) 
        {
            System.out.format("Datei nicht gefunden.
"); //
        }
    }
}

danke

2

Viel mehr als
throw fnfe;
braucht’s da an sich nicht, genaue Aufgabenstellung könnte helfen

3

Ob Sinn macht, Exceptions mit try-catch zu fangen, nur um eine Fehlermeldung zu printen, die genau das anzeigt (eigentlich sogar viel weniger), was die Exception anzeigt, sei mal dahin gestellt. Wenn Du die Exceptions direkt weiter wirfts, wirst Du nämlich Deine methode1 mit entsprechender throws-Klausel deklarieren müssen. Dadurch ist im Prinzip nichts gewonnen. Deswegen ergänzend dazu die Info, dass Exceptions gewrapped und weiter geworfen werden können. Vielfach werden checked Exceptions (wie bspw. FileNotFound) in unchecked Exceptions (wie bspw. RuntimeExeption) gewrapped und weitergeworfen. Das geht so:

throw new RuntimeException(fnfe);
}```
4

Das sollte IMHO aber nicht eine RuntimeException sein, sondern ggf. eine, die von RuntimeException erbt. (Ich bastle u.v.a gerade an einer Reflection-Lib, wo alle möglichen (checked) Exceptions, die bei reflektiven Aufrufen entstehen können, in eine (unchecked) ReflectionException gewrappt werden…)

5

Was spricht gegen eine RuntimeException? Gehts da nur ums naming?

6

Die RuntimeException habe ich nur für den Beispielcode genommen, um das Prinzip zu verdeutlichen. Tatsächlich nimmt man natürlich eher spezifischere Exceptions. Ich verwende beispielsweise sehr häufig IllegalArgumentException und IllegalStateException. Eigene Exception-Klassen setze ich nur sehr sparsam bis überhaupt nicht ein. Ich sehe zwar den Vorteil, mit dem Typen spezifisch arbeiten zu können, aber das brauche ich nur äußerst selten. Das mag anders sein, wenn man eine Lib baut.

7

Volle Zustimmung, IllegalArgumentException reicht für die meisten Fälle aus. Da aber bei einem einzigen, unscheinbaren Reflection-Aufruf durchaus mal 6-8 Checked Exceptions zusammenkommen können, hielt ich es da für angebracht, dem ganzen mal eine gemeinsame, unchecked Exception zu spendieren :wink: (Genaugenommen habe ich die meisten Methoden jetzt in 2 Arten erstellt: *Unchecked und *Optional: Die *Unchecked-Methoden wie getMethodUnchecked werfen eben ggf. eine ReflectionException, und die *Optionals returnen einfach null - ja, ich weiß, das macht man eigentlich nicht, aber Reflection ist eben eine Welt für sich…)

8

Wenn man nur die RuntimeException verwendet, kann man sie nicht im Programm verarbeiten (jedenfalls nicht, ohne den Inhalt der Exception zu analysieren, was zu „instabilem“ Code führen kann). Sei es nur, um in einem GUI eine spezifische Fehlermeldung auszugeben.

9

Stimmt, daran hatte ich jetzt gar nicht gedacht. Aber klar, konkreteren Exceptions kann man besser weiterverarbeiten.