Datei auslesen

huhu ihrs,
hab eine kleine Frage:

Wieso muss das Auslesen einer Datei in einem try-catch-block gemacht werden.

Also ich mein... der Zugriff auf ein Arrayelement muss auch nicht in einem try-catch-block stehen, und wenn ich außerhalb seine Grenzen zugreife kackt das Programm halt ab...

thx schonmal und ein frohes neues

Skym0sh0

das ist eine interessante frage, das würde mich auch interessieren...

vllt ist das mit der datei eifnach ein zwingendes catch oder so, aber ich wüsst enicht dass es verschiedene prioritäten gibt bei try catch

Ich komme nicht aus dem Java-Bereich, aber könnte mir vorstellen, dass die entsprechende Java-Klasse keine andere Möglichkeit bietet zu überprüfen, ob es einen Fehler gab. Vielleicht wird die Exception im Fehlerfall auch direkt im Konstruktor geworfen. In diesem Fall ist eine Exception dringend notwendig.

Sprich:

class File
{
 public File(FileName) { if (!open(FileName)) throw IOException; }
};

Dweb schrieb:

huhu ihrs,
hab eine kleine Frage:

Wieso muss das Auslesen einer Datei in einem try-catch-block gemacht werden.

Also ich mein... der Zugriff auf ein Arrayelement muss auch nicht in einem try-catch-block stehen, und wenn ich außerhalb seine Grenzen zugreife kackt das Programm halt ab...

Bei nem Arrayzugriff ist immer der Programmierer schuld, wenns daneben geht, bei nem Filezugriff nicht, da könnte auch die Datei plötzlich nicht mehr da sein, wenn sie auf nem Netzwerk liegt und die Verbindung abbricht usw...

Skym0sh0

da habt ihr beide recht
es ist aber so

java wirft in beiden fällen eine exception, sowohl beim file zugriff als auch beim array index überschreiten

die exception beim file MUSS man catchen (oder weitergeben)
beim arrray zugriff KANN man sie jedoch fangen, muss aber nicht

Athar

Java unterscheidet da.
Nachfahren von RuntimeException müssen nicht gefangen werden, da sie durch sorgfältiges Programmieren vermeidbar sein sollten.

Athar schrieb:

Nachfahren von RuntimeException müssen nicht gefangen werden, da sie durch sorgfältiges Programmieren vermeidbar sein sollten.

Dazu habe ich gerade auch noch die passende Bestätigung gefunden:

- Es gibt zwei Gruppen von Ausnahmen: checked und unchecked Exceptions.

- Unterklassen von Exception
(außer Unterklassen von RuntimeException) sind Checked Exceptions.
(u.a IOException beim Auslesen einer Datei)

- Der Compiler überprüft NUR die checked Exceptions.
( Darum bringt er einen Fehler, wenn das Auslesen einer Datei nicht im try-catch-block vollzogen wird)

- Unterklassen von RuntimeException sind Unchecked Exceptions.
(u.a. IndexOutOfBoundsException)

Und es steht noch dabei:
Unterklassen der Klasse RuntimeException sollen nie
behandelt werden.

DEvent

Dweb schrieb:

Und es steht noch dabei:
Unterklassen der Klasse RuntimeException sollen nie
behandelt werden.

Das ist richtig. RuntimeExceptions sind immer Programmierfehler, die nur durch sorgsames programmieren vermieden werden können. Eine ArrayOutOfBoundsException oder eine NullPointerException ist immer ein Programmierfehler.

Anderes als andere Sprachen, die keine Checked Exceptions haben, vereint Java die Vorteile von Checked Exceptions (ich weis was eine Methode wirft, weil es zur Methodendefinition gehört) mit denen von Unchecked Exceptions (das sind die Programmierfehler, können überall geworfen werden, deswegen gehören sie nicht zur Methodendefinition).

Wenn eine Klasse/Methode zu viele Exception wirft, kann man einfach eine eigene Exception-Klasse werfen:

class Test {

    public void method_foo() throws MyException {
        try {
            method_foo0();
        } catch (NoSuchFieldException e) {
            throw new MyException(e);
        } catch (NoSuchMethodException e) {
            throw new MyException(e);
        } catch (NotOwnerException e) {
            throw new MyException(e);
        } catch (ParseException e) {
            throw new MyException(e);
        } catch (ParserConfigurationException e) {
            throw new MyException(e);
        }
    }

    private void method_foo0() 
        throws NoSuchFieldException,
        NoSuchMethodException,
        NotOwnerException,
        ParseException,
        ParserConfigurationException
    {
        // do some stuff
    }
}

Dweb schrieb:

Und es steht noch dabei:
Unterklassen der Klasse RuntimeException sollen nie
behandelt werden.

Das ist quatsch, im gegenteil: checked exceptions gelten als Designfehler (in Programmiersprachen allgemein aber vor allem in konkreten APIs) und sollten eigentlich immer durch unchecked exceptions ersetzt werden. Die dilettantische Aufteilung "runtime exceptions = programmierfehler, andere = unbedingt reagieren" ist nicht richtig und führt nur zu Ärger (im Programm).