Exceptions und abstract class

[Googlehupf]

Hallo zusammen,

ich hab hier ein Programm das aus einem Hauptfenster und einem Dialog entsteht, der Dialog wird mittels einem Menu geöffnet. Beim Schließen des Dialogs, werden die Daten(höhe, breite, titel und farbe), die man im Dialog einstellt ins Hauptfenster übertragen, d.h. das Haupfenster nimmt jene Daten an die man im Dialog einstellt. Wenn man das Hauptfenster schließt werden die Daten in ein binär-file gespeichert, beim ausführen das Programms werden diese Daten vom binär-file geladen und das Fenster sieht noch immer so aus wie vorher.

Der Code:

Die Hauptklasse, also da wo das Hauptfenster gestaltet wird.(es gibt zwar noch noch ne Klasse, da steht das void main drinnen etc., aber diese ist unwichtig)

public class MainFrame extends JFrame {
	private JPanel p_center;
	private JPanel contentPane;
	private MyConfigData cfg;
	private static final String CFG_FILE = "mytest.cfg";
	private JMenuItem mi11;

	/**
	 * 
	 */
	public MainFrame() {
		try {
			// Speicher der Konfigurationsdaten beim Schliessen
			this.addWindowListener(new WindowAdapter() {
				public void windowClosing(WindowEvent e) {
					save_Config(cfg);
					System.exit(0);
				}
			});
			cfg = load_Config();
			if (cfg != null) {
				FrameInit();
			} else {
				System.out.println("Error fetching Config Data");
				System.exit(1);
			}
		} catch (Exception exception) {
			exception.printStackTrace();
		}
	}

	private void FrameInit() throws Exception {
		contentPane = (JPanel) getContentPane();
		contentPane.setLayout(new BorderLayout());

		p_center = new JPanel();
		p_center.setBackground(cfg.get_bg());
		contentPane.add(p_center);
		setSize(new Dimension(cfg.get_width(), cfg.get_height()));
		setTitle(cfg.get_title());

		// Menü
		JMenuBar mb = new JMenuBar();
		JMenu m1 = new JMenu("Setup");
		mi11 = new JMenuItem("set Configuration");
		mi11.addActionListener(new Menu_ActionListener());
		m1.add(mi11);
		mb.add(m1);
		this.setJMenuBar(mb);
	}

	// Laden der Konfigurationsdaten
	private MyConfigData load_Config() {
		return load_Config_File();
		// return load_Config_Reg();
	}

	// Speichern der Konfigurationsdaten
	private void save_Config(MyConfigData mcd) {
		save_Config_File(mcd);
		// save_Config_Reg(mcd);
	}

	// Speichern der Konfigurationsdaten in Konfigdatei
	private void save_Config_File(MyConfigData mcd) {
		// // Speichern in Config-Datei
		try {
			FileOutputStream fs = new FileOutputStream(CFG_FILE);
			ObjectOutputStream os = new ObjectOutputStream(fs);
			os.writeObject(mcd);
			os.close();
		} catch (Exception e) {
			e.printStackTrace();
		}

		System.out.println("CFG gespeichert \n");
	}

	
	// Laden der Konfigurationsdaten aus Konfigdatei
	private MyConfigData load_Config_File() {
		MyConfigData mcd = null;
		// // Laden aus Konfigurationsdatei
		try {
			FileInputStream fs = new FileInputStream(CFG_FILE);
			ObjectInputStream is = new ObjectInputStream(fs);
			mcd = (MyConfigData) is.readObject();
			is.close();
			System.out.println("CFG von Datei geladen \n");
		} catch (FileNotFoundException e) {
			// Erstinitialisierung, wenn keine Config-Datei
			mcd = new MyConfigData(800, 600, Color.RED, "Titel");
			System.out.println("CFG neu erzeugt \n");
		} catch (Exception e) {
			e.printStackTrace();
		}
		return mcd;
	}

	
	private void menu_Handler(ActionEvent e) {
		new MyConfigDialog(this, cfg);
		p_center.setBackground(cfg.get_bg());
		setSize(new Dimension(cfg.get_width(), cfg.get_height()));
		setTitle(cfg.get_title());
		validate();
	}

	private class Menu_ActionListener implements ActionListener {
		public void actionPerformed(ActionEvent e) {
			menu_Handler(e);
		}
	}
}

Die Klasse, die serializable implementiert bzw. von denen die Daten gesichert werden.

import java.io.Serializable;
import java.awt.*;


public class MyConfigData implements Serializable {
	private int width;
	private int height;
	private Color bg;
	private String title;
	
	/**
	 * 
	 * @param width   -  Fensterbreite
	 * @param height  -  Fensterhöhe
	 * @param bg      -  Hintergrundfarbe
	 * @param title   -  Fenstertitel
	 */
	public MyConfigData(int width, int height, 
			Color bg, String title) {
		this.width = width;
		this.height = height;
		this.bg = bg;
		this.title = title;
	}
	
	/**
	 * Lesen der Fensterbreite
	 * @return
	 */
	public int get_width () {
		return width;
	}
	
	/**
	 * Lesen der Fensterhöhe
	 * @return
	 */
	public int get_height () {
		return height;
	}
	
	/**
	 * Lesen der Hintergrundfarbe
	 * @return
	 */
	public Color get_bg () {
		return bg;
	}
	
	/**
	 * Lesen des Fenstertitels
	 * @return
	 */
	public String get_title () {
		return title;
	}
	
	/**
	 * Setzen der Fensterbreite
	 * @param val
	 */
	public void set_width (int val) {
		width = val;
	}
	
	/**
	 * Setzen der Fensterhöhe
	 * @param val
	 */
	public void set_height (int val) {
		height = val;
	}
	
	/**
	 * Setzen der Hintergrundfarbe
	 * @param val
	 */
	public void set_bg (Color val) {
		bg = val;
	}
	
	/**
	 * Setzen des Fenstertitels
	 * @param val
	 */
	public void set_title (String val) {
		title = val;
	}
}

Klasse zum Farbe auswählen:

import java.awt.*;
import javax.swing.*;


public class ColorSet extends ColorSetter {
	private Color col;
	private JRadioButton rb_r;
	private JRadioButton rb_g;
	private JRadioButton rb_b;
	
	/**
	 * 
	 * @param col  -  aktuelle Farbe
	 */
	public ColorSet (Color col) {
		this.col = col;
		setLayout (new GridLayout(3,1));
		rb_r = new JRadioButton("RED");
		rb_g = new JRadioButton("GREEN");
		rb_b = new JRadioButton("BLUE");
		this.add(rb_r);
		this.add(rb_g);
		this.add(rb_b);
		ButtonGroup bg = new ButtonGroup();
		bg.add(rb_r);
		bg.add(rb_g);
		bg.add(rb_b);
	}
	
	/**
	 * Abfrage der ausgewählten Farbe
	 */
	public Color get_Color() {
		if (rb_r.isSelected()) {
			col=Color.red;
		} 
		else if (rb_g.isSelected()) {
			col=Color.green;
		}
		else {
			col=Color.blue;
		}
		return col;
	}
}

Abstrakte Klasse:

import java.awt.*;
import javax.swing.*;

public abstract class ColorSetter extends JPanel{

	abstract public Color get_Color();
}

Exceptions:
Also es gibt ja da so nen try catch-block. Im try-Block wird irgendein Programmcode geschrieben, da kann ein Fehler auftreten, meinstens wenn ein Fehler auftritt, dann wird ja das Programm gestoppt, aber dieser catch fängt den Fehler ab und löst ihn? Richtig?
Und dann gehts ganz normal weiter.
Die Frage ist nun wo brauche ich den überall einen try-catch-block. Ich sehe jetzt nur da try-catch-blöcke, da wo eine aufgerufen wird in dem try-block, also FrameInit, oder DigInit. Hat das nen Grund? Oder wie weiß ich wann ich so was machen muss?

Welche Fehler werden denn da bei mir behandelt in den Klasse MainFrame, myDialog?

z.b. bei: FileNotFoundException, wenn im try-block versucht wird ein File zu öffnen, aber es nicht existiert, dann wird halt das so gelöst wie es bei mir da steht, right?

Was bedeutet aber nur "Exception", also beim catch? Wie gesagt welche Fehler können da auftreten? Für mich sieht das nicht nach einer Lösung aus, was da im catch-Block steht(Klasse MainFrame und myDialog). In den jeweiligen try-Blöchen werden ja die Methoden FrameInit bzw. DigInit oder so aufgerufen, warum steht bei den Methoden "throws Exception" da? Was macht das?

Abstrakte Klasse:
Also könnt ihr mir bitte den Teil in meinen Programm erklären was diese abstrakte Klasse da macht und für was die in meinem Fall jetzt gut ist. Also ich verstehe auch nicht warum wir die alte Frabe im DigInit holen und dann ins ColorSet übegeben, hat wahrscheinlich auch was mit den abstrakten Klassen zu tun.

Danke!

PS: Ich hab mir zwar über exceptions und abstract classes bei galileo computing was durchgelesen, aber leider hat es nichts wirklich geholfen.

mfg

 

[saftmeister]

Zu den Exceptions:

Die Klasse "Exception" ist eine Basis-Klasse aus der Java-Runtime. Man kann von Exception ableiten und damit eigene Exception-Klassen erzeugen. FileNotFoundException ist z.B. so eine abgeleitete Klasse. Wenn eine Methode "throws Exception" stehen hat, bedeutet das, dass sie eine Exception werfen kann, die von der Klasse "Exception" abgeleitet ist, also so gut wie jede Exception. Es gibt nur wenige Exception-Klassen, die nicht von Exception abgeleitet sind. Dazu gehören z.B. OutOfMemoryError oder IOError. Die Ur-Klasse aller Ausnahmen ist Throwable. Du kannst also mit

try
{
}
catch(Throwable t)
{
  /// Die Ausnahme behandeln...
}

alle Exceptions abfangen und zu mindest einen Stack-Trace ausgeben:

catch(Throwable t)
{
  t.printStackTrace();
}

Damit erfährst du, wo der Fehler aufgetreten ist, bekommst einen Call-Stack, also den Stapel aller Funktionsaufrufe bis zu deinem Fehler und den Grund des Fehlers.


Zu der abstrakten Klasse: Abstrakte Klassen erstellt man, wenn man einen rohen Bauplan notieren will, auf dem man weitere Klassen aufbaut. Abstrakte Klassen kann man einsetzen, wenn man kein Interface benutzen möchte. Es kann sinnvoll sein, eine abstrakte Klasse einem Interface vorzuziehen, wenn in der Klasse bereits Implementierung vorgenommen werden soll.

Abstrakt definierte Methoden müssen in der abgeleiteten Klasse implementiert werden, es herrscht also ein Implementierungszwang, wie bei Interfaces. Aber nicht alle Methoden einer abstrakten Klasse müssen abstrakt sein, diese müssen dann auch nicht in der abgeleiteten Klasse implementiert werden. Beispiel:

public abstract class A
{
  // Hier muss eine abstrakte Methode implementiert werden
  abstract public void machWas();
  
  // Diese Methode ist nicht abstrakt und muss nicht implementiert werden
  public void machWasAnderes()
  {
      System.out.println("Was völlig anderes");
  }
}

public class B extends A
{
    @Override
    public void machWas()
    {
        System.out.println("Mach was");
        
        this.machWasAnderes();
    }  
}

Bei deinem Beispiel könnte man auch ein Interface nehmen. Kann man nicht, denn die Klasse ColorSetter soll ja JPanel ableiten. JPanel ist eine Klasse, also kann man auch nur eine Klasse ableiten. Wenn JPanel ein Interface wäre, könnte man ein Interface mit extends ableiten. So geht das also aber nicht. Daher ist hier nur eine abstrakte Klasse möglich.

 

[Googlehupf]

Danke!

Das man hier keine Interfaces benutzen kann verstehe ich. Nur eins verwirrt mich an Abstrakten Klassen und Interfaces.
Mann muss immer folgender Maßen initialisieren/definieren "Interface" "name" = new "Klasse, die das Interface implementiert"();

Ist denn "Klasse, die das Interface implementiert" "name" = new "Klasse, die das Interface implementiert"(); eigentlich das gleiche oder? Weil die Klasse, die das Interface implementiert ist ja auch ein, Typ von Interface. Es handelt sich hier zwar um Abstrakte Klassen, aber das Prinzip was ich meine ist doch dasselbe, oder?

Auf mein Bsp bezogen:

ColorSetter name = new ColorSet();
// ist das selbe wie 
ColorSet name = new ColorSet();
//Weil ColorSet im Prinzip ein ColorSetter ist, weil ColorSet ColorSetter implementiert. Ist das so richtig?

Weil mich hat das verwirrt, da in manchen Beispielen das Interface definiert wird.

Zum Beispiel hier:

interface Buyable() {
    public int getPrice();
}
 
class Car implements Buyable{
 
    @Override
    public int getPrice() {
        return 15000;
    }
}
 
class Truck implements Buyable{
 
    @Override
    public int getPrice() {
        return 45000;
    }
}
 
class Motorbike implements Buyable{
 
    @Override
    public int getPrice() {
        return 8000;
    }
}



class CarDealer {
 
    private int billingAmount;
 
    public void buyBuyable(Buyable b) {
        billingAmount += b.getPrice();
    }
    
    public void printBill() {
        System.out.println("Der Betrag Ihres Einkaufs beläuft sich auf:");
        System.out.println(billingAmount + " €.");
        System.out.println("Danke für Ihren Einkauf bei MegaMüll Vehicles.");
    }
}

	

public class Buy {
 
    public static void main(String[] args) {
        CarDealer carDealer = new CarDealer();
        carDealer.buyBuyable(new Car());
        carDealer.buyBuyable(new Truck());
        carDealer.buyBuyable(new Motorbike());
        carDealer.printBill(); 
    }
}

Hier wird ja das gemacht, wie oben beschrieben: Buyable b = new Car(); (also: "Interface" "name" = new "Klasse, die das Interface implementiert"()

Und in meinem Programm kann ich beides machen, wie ich oben schon gesagt habe. Nur hier im 2ten Beispiel funktioniert das nicht, weil es mehrere Klassen gibt die das Interface implementieren, darum kann man das nicht anwenden wie ich es ganz oben beschrieben habe.

Also eigentlich sind Abstrakte Klasse und Interfaces gleich, nur bei Abstrakte Klassen kann ich nur einmal ableiten, Interfaces dafür oft implementieren, also verschiedene.

Und bei der Abstrakten Klasse muss ich nur die Abstrakten Methoden in der jeweiligen Klasse implementieren.

Aber ganz ehrlich: Diese Abstrakte Klassen anwendung im 1ten Programm ist ja sowas von Sinnlos, weil man es ja einfach auch ohne machen könnte --> Einfach ColorSet direkt von JPanel ableiten und fertig.


Ein weiteres Beispiel:

    interface Motor {
            public void starten();
    }
     
    public class BmwMotor implements Motor {
            public void starten();
    }
     
    public class AudiMotor implements Motor {
            public void starten();
    }
     
    public class Auto {
            private Motor motor;
           
            public void fahren() {
                    this.motor.starten();
            }
           
            public void setMotor(Motor m) {
                    this.motor = m;
            }
    }
     
    public class Main {
            public static void main {
                   
                    Auto auto = new Auto();
                    Motor audiMotor = new AudiMotor();
                    auto.setMotor(audiMotor);
                    auto.fahren();         
                   
                    Motor bmwMotor = new BmwMotor();
                    auto.setMotor(bmwMotor);
                    auto.fahren();
            }
     
    }

Ok das zum Beispiel kann ich gar nicht nachvollziehen, das verwirrt mir nur, dass 2te Beispiel ist hingegen net so schwer. Kannst du mir bitte dieses 3te Beispiel erklären bzw. zeigen das es eig. nach dem gleichen Prinzip wie das 2te funktioniert?
Würde mich echt freuen!


Kurz noch zu den Exceptions:

Ok, also dieses Throwable ist also die oberste Klasse und catched alle Exceptions und wenn ich nur Exception schreiben, dann cachts es auch viele, nur halt nicht alle, richtig?

Und im catch-block macht man dann eine stacetrack ausgabe, da ich dann selbe sehen kann was falsch ist, richtig?

Und warum wende ich diese try-catch-blocks genau da an wo ein Fenster erzeugt wird irgendwie? ^^ Oder wo eine Methoden aufgerufen wird: FrameInit und DigInit?

Ich weiß es sind einige Frage, aber ich möchte das einfach wissen.

Danke im voraus!

Gruß

 

[sheel]

...
...
Und in meinem Programm kann ich beides machen, wie ich oben schon gesagt habe. Nur hier im 2ten Beispiel funktioniert das nicht, weil es mehrere Klassen gibt die das Interface implementieren, darum kann man das nicht anwenden wie ich es ganz oben beschrieben habe.

Genau so ists.
Du bekommst das gleiche Objekt, die Frage ist eben nur,
wie "austauschbar" das bezogen auf den Variablentyp ist.

Also eigentlich sind Abstrakte Klasse und Interfaces gleich, nur bei Abstrakte Klassen kann ich nur einmal ableiten, Interfaces dafür oft implementieren, also verschiedene.

Und bei der Abstrakten Klasse muss ich nur die Abstrakten Methoden in der jeweiligen Klasse implementieren.

Eine abstrakte Klasse ist ein Interface, bei dem aber teilweise die Methoden schon
fertigprogrammiert sind (beim Interface ist ja kein "Inneres" der Methoden erlaubt).

Java erlaubt einer Klasse ja prinzipiell nur von max. einem Etwas zu erben,
dass ausführbaren Code beinhaltet (meiner Meinung nach Schwachsinn, aber was solls)
Eine Klasse kann also von einer anderen fertigen oder abstrakten Klasse erben,
zusätzlich noch beliebig viele Interfaces.

Ein weiteres Beispiel:
//Auto-Motor-Beispiel
Ok das zum Beispiel kann ich gar nicht nachvollziehen, das verwirrt mir nur, dass 2te Beispiel ist hingegen net so schwer. Kannst du mir bitte dieses 3te Beispiel erklären bzw. zeigen das es eig. nach dem gleichen Prinzip wie das 2te funktioniert?
Würde mich echt freuen!

Der Code kann so nicht gehen.
Also kein Wunder, wenns einen verwirrt.


Etwas zu den Exceptions kommt noch.

 

[Googlehupf]

Sheel? Was wolltest du zu den Exceptions noch sagen .

Abstrakte Klasse: Es gibt darin fertige Methoden und nicht fertige. Die nicht fertigen sind abstrakte Methoden und müssen in der Klasse stehn, die von der Abstract class erbt.

Interface: Wenn mehrere Klassen diesselbe Methode benutzen wollen, können sie auf ein Interface zugreifen und können dann diese Methode benutzen. Die Klassen müsse aber alle vom Typ Interface sein. Dasselbe gilt eig. für abstrakte Klassen ja auch, oder?

Stimmt das so in etwa?
Naja und die Fragen zu den Exceptions sind eh noch offnen.

Andere Frage:
Im try-Block sind ja die WindowListener --> Warum macht man denn die grad darin? Wieso net im FrameInit bzw. im dglinit?

 

[saftmeister]

Stimmt das so in etwa?

Prinzipiell schon, nur das Konzept ist ein anderes. Eine Schnittstelle definiert man, um die dahinter liegende Implementierung nicht offen legen zu müssen oder wenn zur Compile-Zeit nicht klar ist, welchen Typ ein Objekt zur Laufzeit sein soll. Dann kann man sich eine Fabrik bauen und liefert "einfach" ein Objekt an ein Interface:

Schnittstelle fabrikObjekt = Fabrik.methode(Paramater....);

Naja und die Fragen zu den Exceptions sind eh noch offnen.

Welche genau?

Andere Frage:
Im try-Block sind ja die WindowListener --> Warum macht man denn die grad darin? Wieso net im FrameInit bzw. im dglinit?

Weil man Listener frühst möglich registrieren will. Sie können Ereignisse abfangen und da Ereignisse die Eigenschaft haben, zu den ungünstigsten Zeitpunkten einzutreten, reagiert man möglichst früh darauf. FrameInit ist schon spät, denn da gibt es schon einige Objekte, die Ereignisse auslösen können.

 

[Googlehupf]

Sorry, aber ich verstehe nicht was du meinst bei den Interfaces, kannst du mir das vielleicht näher veranschaulichen?

Und das mit den abstrakten Klassen habe ich auch richtig gesagt?

Exceptions:
Also dieses Throwable ist also die oberste Klasse und catched alle Exceptions und wenn ich nur Exception schreiben, dann cachts es auch viele, nur halt nicht alle, richtig?

Und im catch-block macht man dann eine stacetrack ausgabe, da ich dann selbe sehen kann was falsch ist, richtig?

Und warum wende ich diese try-catch-blocks genau da an wo ein Fenster erzeugt wird irgendwie? Oder wo eine Methoden aufgerufen wird: FrameInit und DglInit?

Und warum steht nochmal bei den Methoden dabei "throws Exceptions", was bringt das im Zusammenhang mit try-catch?

 

[saftmeister]

Sorry, aber ich verstehe nicht was du meinst bei den Interfaces, kannst du mir das vielleicht näher veranschaulichen?

Ok, hab schon verstanden, nicht alles auf einmal. Wir klären hier erstmal deine Fragen zu Exceptions und der abstrakten Klasse.

Und das mit den abstrakten Klassen habe ich auch richtig gesagt?

Ja, an der Definition gibt es nix zu rütteln.

Exceptions:
Also dieses Throwable ist also die oberste Klasse und catched alle Exceptions und wenn ich nur Exception schreiben, dann cachts es auch viele, nur halt nicht alle, richtig?

Genau, denn neben Exception gibt es noch Error was von Throwable ableitet und von der Klasse Error leiten auch noch ein paar ab. Zum mindest wenn man rein die JRE betrachtet. Natürlich steht es dir frei, weitere Klassen zu erstellen, die von Error ableiten, und von deiner neuen Error-Klasse wieder ableiten und so weiter und so fort. Dann würden in dem Fall auch nur die Exceptions abgefangen, die von Exception ableiten.

Und im catch-block macht man dann eine stacetrack ausgabe, da ich dann selbe sehen kann was falsch ist, richtig?

Das liegt in deinem Ermessen. Ich würde versuchen evtl. Ressourcen freizugeben und eine qualifizierte Meldung an den Benutzer schicken. Für den Anfang ist aber ein printStackTrace() sinnvoller, um die Eigenarten kennen zu lernen.

Und warum wende ich diese try-catch-blocks genau da an wo ein Fenster erzeugt wird irgendwie? Oder wo eine Methoden aufgerufen wird: FrameInit und DglInit?

Weil nur Exceptions abgefangen werden können, von Methoden, die sich innerhalb eines try-Code-Bodies befinden.

Und warum steht nochmal bei den Methoden dabei "throws Exceptions", was bringt das im Zusammenhang mit try-catch?

Um dem Entwickler, der die entsprechende Methode verwenden will darauf hinzuweisen: "Achtung, diese Methode kann Fehler verursachen, die nicht von der Methode selbst behandelt sondern stattdessen an den Aufrufer geworfen werden.

Achtung! Nicht jede Methode, die keine "throws"-Deklaration stehen hat, wirft auch keine Exceptions. Du kannst dir also sicher sein, das wenn eine Methode "throws Throwable" oder dergleichen stehen hat, diese Fehler im Zweifelsfall auch wirft. Aber eine Methode ohne diese Angabe garantiert dir nicht, das nicht doch ein Fehler auftreten kann, der über eine Laufzeit-Ausnahme (RuntimeException und Ableitung der selben) nicht doch an deinen Aufruf geleitet werden und dann dort behandelt werden müssen.

 

[Googlehupf]

Ich hab nun ein Programm geschrieben, das eine Textdatei öffnen bzw. speichern kann.

Hier der Code:

package file_uebung;

import javax.swing.*;
import java.io.*;
import java.awt.*;
import java.awt.event.*;

public class MyDatei extends JFrame {
	private JPanel contentPane;
	private JMenuBar bar = new JMenuBar();
	private JMenu menu = new JMenu("File");
	private JMenuItem m_item = new JMenuItem("Save");
	private JMenuItem m_item2 = new JMenuItem("Open");
	private JTextArea text = new JTextArea();
	private FileDialog file_dgl;

	public MyDatei() {
		try {
			setDefaultCloseOperation(EXIT_ON_CLOSE);
			jbInit();
		} catch (Exception exception) {
			exception.printStackTrace();
		}
	}

	/**
	 * Component initialization.
	 * 
	 * @throws java.lang.Exception
	 */
	private void jbInit() throws Exception {
		contentPane = (JPanel) getContentPane();
		contentPane.setLayout(new BorderLayout());
		setSize(new Dimension(400, 300));
		setTitle("my_Datei2");

		bar.add(menu);
		menu.add(m_item);
		menu.add(m_item2);

		contentPane.add(text, BorderLayout.CENTER);

		Button_Listener bal = new Button_Listener();

		m_item.addActionListener(bal);
		m_item2.addActionListener(bal);

		this.setJMenuBar(bar);

	}

	private void buttonHandler(ActionEvent ae) {

		if (ae.getSource() == m_item) {

			try {
				FileDialog fd = new FileDialog(this,
						"Bitte Speicherort auswaehlen!", FileDialog.SAVE);
				fd.setVisible(true);
				String filename = fd.getDirectory() + fd.getFile();
				System.out.println(filename);
				FileWriter fw = new FileWriter(filename);
				BufferedWriter bw = new BufferedWriter(fw);

				int lines = text.getLineCount();

				for (int x = 0; x < lines; x++) {
					int start = text.getLineStartOffset(x);
					int len = text.getLineEndOffset(x) - start - 1;

					if (len < 0)
						len = 0;

					bw.write(text.getText(start, len));
					bw.newLine();
				}

				bw.close();

			} catch (Exception e) {
				e.printStackTrace();
			}

		} else {

			try {
				FileDialog fd = new FileDialog(this,
						"Waehlen Sie eine Datei aus", FileDialog.LOAD);
				fd.setVisible(true);

				String filename = fd.getDirectory() + fd.getFile();

				FileReader fr = new FileReader(filename);
				BufferedReader myReader = new BufferedReader(fr);

				String line = myReader.readLine();
				// text.setText(line);
				while (line != null) {
					text.append(line + "\n");
					line = myReader.readLine();
				}

				myReader.close();
			} catch (Exception e) {
				e.printStackTrace();
			}

		}
	}

	private class Button_Listener implements ActionListener {
		public void actionPerformed(ActionEvent ae) {
			buttonHandler(ae);
		}
	}

}

Passt das eh so, dass ich 2 try-catches mache, also pro so lesen bzw. schreiben einen, oder könnte ich einen über das ganze drüber ziehen?

Wie z.B. könnte ich die Exception behandeln, wenn ich auf "Abbrechen" beim FileDialog drücke? Oder z.B. FileNotFoundException? Was könnte ich dann im catch schreiben?