Informationen speichern

[Digedag]

Hallo ich versuche gerade Informationen meines Programmes in einer Datei zu speichern.
Der Compiler spuckt eine Fehlermeldung bei folgendem Code aus:

    public void Ende(){
        int i;
        File Datei = new File("Test.txt");
    -->FileWriter ausgabestrom = new FileWriter(Datei);
        PrintWriter ausgabe = new PrintWriter(ausgabestrom);
        for (i=98;i>-1;i--){
        System.out.println("Zeile"+i+": "+Zeile[i].getText());
        ausgabe.println(Zeile[i].getText());
        }
        ausgabe.close();
        System.exit(0);
    }

Die Fehlermeldung lautet: "unreported exception java.io.IOException; must be caught or declared to be thrown"
Ich habe noch keine Ahnung von Exceptions und eigentlich hatte ich es bei einem derart simplen Programm auch noch nicht vor mich damit zu beschäftigen.
Kann mir jemand sagen was genau der Compiler von mir erwartet?

Als alter Turbo Pascaler würde ich gerne mal die Befehle von Turbo Pascal auf Java übertragen (bzw. umgekehrt).
Kann man das folgendermaßen vegleichen:
assign(Datei,"Test.bat"); ~ File Datei = File("Test.bat");
rewrite(Datei); ~ File Datei = new File("Test.bat");
close(Datei); ~ Datei.close();
append(Datei); ~ macht Java beim öffnen einer Datei automatisch

Gibt es bei Java auch einen Dateizeiger? Bei Turbo Pascal setzte man diesen beim Lesen i.d.R. zurück mit reset(Datei);

Falls ich irgendwie voll kommen auf dem Schlauch stehe dann möchte ich darüber natürlich aufgeklärt werden.
Falls einer der Meinung ist er hätte eine bessere oder geeignetere Methode parat dann soll er mir diese gerne mitteilen. Bei Java scheint es ja so zu sein, dass es für die einfachstenm Probleme meistens gleich mehrere Lösungen gibt. Das finde ich sehr verwirrend.

 

[byte]

Die Fehlermeldung sagt eigentlich alles: Du musst die Ausnahme IOException entweder abfangen oder aus dem Kontext der Methode werfen.

Mach am besten ein Try / Catch in die Methode

public void ende() {
   try {
      ...
   } catch(IOException ioe) {
      ioe.printStackTrace();
   }
}

Andere Möglichkeit:

public void ende() throws IOException {
   ...
}

Aber damit verlagerst Du das Problem nur an eine andere Stelle, nämlich überall dort, wo Du diese Methode aufrufst.


PS: Methodennamen und Variablen beginnen in Java grundsätzlich mit einem Kleinbuchstaben...

 

[millinär]

try{   public void Ende(){
        int i;
        File Datei = new File("Test.txt");
    -->FileWriter ausgabestrom = new FileWriter(Datei);
        PrintWriter ausgabe = new PrintWriter(ausgabestrom);
        for (i=98;i>-1;i--){
        System.out.println("Zeile"+i+": "+Zeile[i].getText());
        ausgabe.println(Zeile[i].getText());
        }
        ausgabe.close();
        System.exit(0);
    }
catch(IOException e){

}
}

probiers mal so

 

[Murray]

Ohne millinär zu nahe treten zu wollen: vergiss den letzten Tip ganz schnell.

Grund: der Compiler mag mit der Lösung zufrieden sein, weil die Exception ja abgefangen wird; behandelt wird sie aber nicht. Wenn hier ein Fehler auftritt (z.B. weil man im aktuellen Verzeichnis keien Shcreibrechte hat), dann merkt man das nicht.
Also: im catch-Block mindestens ein System.out.println( e), besser ein e.printStackTrace(), noch besser eine der jeweiligen Anwendung angepasste Behandlung.

 

[millinär]

catch(IOException e){
System.out.println("i habs file net gefunde i glaub 
des isch i nem andern ordner oder mei 
 feschtplatte hat zuviel gesoffe und morge weis si net mehr was sie gemacht hat");
}

 

[byte]

Das try/catch is auch nich wirklich da, wo es hingehört in Deinem Code.

 

[Einwegdose]

Wieso eigentlich FileWriter -> PrintWriter .. ka ich nehm lieber den BufferedWriter :?
Und das man nen t/c um ne ganze Methode macht hab ich auch noch nicht gesehen

Mein Vorschlag:

public void ende(){
 try {
  BufferedWriter out = new BufferedWriter(new FileWriter(new File("./Test.txt")));
  for (int i=98;i>-1;i--){
   System.out.println("Zeile"+i+": "+Zeile[i].getText());
   out.write(Zeile[i].getText());
   out.newLine();
  }
 } catch ( IOException ioe ) {
    System.out.println("Fehler beim Schreiben:\r\n"+ioe.printStackTrace());
   }
 out.close();
  System.exit(0);
}

 

[millinär]

ich mach das immer so lol ich nehm auch immer nur Exception in letzter zeit throw ich sogar alles immer bis zur main methode viele exceptions sind ja auch unrealistisch wenn ich z.b. weis das ein programm vermutlich sowieso keine exception auslöst wenn ichs richtig programmiert habe kann ichs mir auch sparen

ist natürlich nicht zur nachahmung zu empfehlen ist ne schlecht angewohnheit

 

[Einwegdose]

Naja das kommt immer darauf an, wenn du z.B. ein Programm mit Benutereingaben hast kannst du dir nie sicher sein was eingegeben wird .. aber auch wenn das Programm Daten einliest oder so etwas kann es ja immer mal sein dass die Daten korrupt sind.

Von daher sind sie schon ganz sinnvoll

 

[Leroy42]

Als alter Turbo Pascaler würde ich gerne mal die Befehle von Turbo Pascal auf Java übertragen (bzw. umgekehrt).
Kann man das folgendermaßen vegleichen:
assign(Datei,"Test.bat"); ~ File Datei = File("Test.bat");
rewrite(Datei); ~ File Datei = new File("Test.bat");
close(Datei); ~ Datei.close();
append(Datei); ~ macht Java beim öffnen einer Datei automatisch

Pascal und auch C hatten nur eine ganz rudimentäre byte-orientierte
Dateibehandlung. Löse dich am besten und arbeite dich am besten
anhand eines Buches in das package java.io ein, da Dateien/Streaming
in Java weitaus umfangreicher sind.

Dateizeiger gibt es in der Klasse java.io.RandomAccess...

 

[Lim_Dul]

ich mach das immer so lol ich nehm auch immer nur Exception in letzter zeit throw ich sogar alles immer bis zur main methode viele exceptions sind ja auch unrealistisch wenn ich z.b. weis das ein programm vermutlich sowieso keine exception auslöst wenn ichs richtig programmiert habe kann ichs mir auch sparen

ist natürlich nicht zur nachahmung zu empfehlen ist ne schlecht angewohnheit

Die Checked Exceptions, insbesondere die IOException sind Exceptions, die trotz korrekt programmierten Code auftreten können.

Sobald man anfängt Netzwerkkommunikation zu machen, werden zwangsläufig IOExceptions auftreten.

 

[Digedag]

Danke sehr für die Antworten. Es klappt alles so wie ich es mir vorgestellt habe.

Wenn ich das mit "printStackTrace()" richtig verstanden habe wird im Fehlerfall ein Text ausgegeben. Z.B. "error - not able to write into Test.txt".

@ Leroy42: Ich habe mir schon gedacht dass man das nicht mit Turbo Pascal vergleichen kann.

@ Einwegdose: Da hast du natürlich Recht. Wäre ja unschön wenn ich im Fehlerfall das Programm nicht beenden könnte.

BufferedWriter macht einen guten Eindruck. Aber wieso erst write und dann newLine? Gibt es denn keine writeln? Kann man bei BufferedWritter auch print und println einsetzen?

 

[Leroy42]

Kann man bei BufferedWritter auch print und println einsetzen?

Pack den BufferedWriter noch in einen PrintWriter und du hast print und println
für alle Datentypen überlagert.

Das Pascal'sche write und writeln hat die Problematik, daß deren Syntax
außerhalb von Pascal liegt (writeln(myFloat:6:2)) und somit derartige Funktionen
nicht selbst in der Sprache nachgeschrieben werden können; was C und Java
vermeiden wollten.

C führte die Funktion printf für formatierte Ausgaben und das varargs-Konzept
für die Übergabe einer variablen Anzahl von Parametern beliebigen Typs ein
ohne die C-Syntax zu verlassen.

Das ganze krankte allerdings an der unsicheren Umsetzung, indem Pointer
auf den Stack rumfriemelten und weder zur Compilezeit noch zur Laufzeit
geprüft werden konnte ob die Anzahl und Typen der übergebenen Parameter
korrekt sind, was schnell zu unkontrollierten Zugriff (printf) oder gar Überschreiben (scanf)
führen konnte.

Java geht da seit 1.5 endlich einen sauberen Weg, der dir spätestens zur Laufzeit
sagen kann, daß der Formatstring nicht zu den übergebenen Argumenten paßt.
Zusammen mit dem Prinzip des Autoboxings/unboxings von Daten primitiven Typs
hat man nun alle gewünschten Möglichkeiten (Den Overhead des Autoboxings kann
man für reale Programme vernachlässigen), so daß das printf einer Instanz
der Klasse Printer (oder String.format) dem Pascal'schen writeln in nichts mehr nachsteht.

Ich persönlich finde die Möglichkeiten die der Formatstring zur Verfügung stellt
schon gut durchdacht und ausgereift. Z.B. paßt der Formatstring
"%,20d"
auf jeden Ganzzahltyp wie byte, short, int, long und sogar BigInteger.

Dieser Code

		System.out.printf("%,30d%n", 42);
		System.out.printf("%,30d%n", new BigInteger("123456789123456789123"));

erzeugt, wie erwartet:

                           42
   123.456.789.123.456.789.123

für das deutsche Locale.