Swing Exception's und MVC

[headnut]

Guten Abend

Bevor ich mich grossartig wierder mal in was verrenne möchte ich eure Meinung dazu hören. Ich habe ein GUI erstellt mit einer MVC Architektur. Nun setehe ich vor dem Exceptionhandlin und frage mich wie ich dieses angehen soll.

Irgendwie fehlt mir komplett die Idee.

Soll ich für jeden Exceptiontyp eine eigene Klasse erstellen und diese Via Controller ansprechen?

Danke schonmal für alle ideen.

 

[Marco13]

Eigene Exception-Klassen braucht man SEHR selten. Beschreib' mal genauer was du meinst (ggf. mit einem (Pseudo)code-Beispiel)

 

[headnut]

manchmal frage ich mich für was ich geld ausgebe für Kurse in java... Dort macht man das mit eigenen Klassen...

Bevor ich mit code komme vielleicht ein Beispiel:

Per TCP kommen daten an, wenn keine kommen, oder die verbindung nicht aufgbeuat werden konnte werden Exceptions geworfen. Aber ich kann doch nicht immer im Code :

try {

} catch(ioexception e) {
... lösung des problems
}

schreiben, das wird ja extrem unübersichtlich...

 

[irgendjemand]

doch ... genau so oder eben über [c]throws[/c] an den caller weiter werfen ...

eigene Exceptions sollte man vermeiden da diese größtenteils eh nur von RuntimeException abgeleitet werden und meist andere checked Exceptions kapseln -> dirty code ...

also : auf checked exceptions angemessen reagieren und nicht in unchecked exceptions kapseln und alles was unchecked sein soll entweder als normale RuntimeException oder meinet wegen auch von dieser ableiten ... wobei es denke ich mal genug passende RuntimeException's gibt ...

 

[tfa]

das wird ja extrem unübersichtlich...

Ja, leider. Unglücklicherweise gibt es in Java checked Exceptions und die Standard-API verwendet sie leider recht häufig.
Meistens (wenn sie nicht an Ort und Stelle behandeln kann) ist es am sinnvollsten, sie in Runtime-Exceptions zu kapseln und weiter zu werfen (löst das Problem der Unübersichtlichkeit nur bedingt) und sie an einer zentralen Stelle zu fangen und zu behandeln.

 

[irgendjemand]

Ja, leider. Unglücklicherweise gibt es in Java checked Exceptions und die Standard-API verwendet sie leider recht häufig.
Meistens (wenn sie nicht an Ort und Stelle behandeln kann) ist es am sinnvollsten, sie in Runtime-Exceptions zu kapseln und weiter zu werfen (löst das Problem der Unübersichtlichkeit nur bedingt) und sie an einer zentralen Stelle zu fangen und zu behandeln.

aber wäre das nicht ziemlicher dirty-code ?
ja : ich gebe mich ja geschlagen das es sicher in spezial-fällen irgendeinen sinn macht ... aber hat man nicht genau dafür den unterschied zwischen (un)checked Exceptions durch RuntimeException geschaffen ?

 

[Gast2]

aber wäre das nicht ziemlicher dirty-code ?

Warum solllte es dirty sein?

 

[irgendjemand]

"checked Exception in unchecked Exception kapseln" ...

sagt eigentlich alles oder ?
checked Exceptions sind dazu da damit man auf sie reagiert und sie behandelt ... ansonsten wäre einer unterscheidung zwischen checked und unchecked doch sinnlos und ist somit sicher nicht im sinne dieser idee

 

[tfa]

aber wäre das nicht ziemlicher dirty-code ?

Nö, solange die Exceptions nicht verschluckt werden.

aber hat man nicht genau dafür den unterschied zwischen (un)checked Exceptions durch RuntimeException geschaffen ?

Das hat man sich mal so gedacht. Aber die Idee hat sich als doch nicht so toll heraus gestellt.
Checked Exception sollte ja bedeuten, man kann sie sofort auffangen um sie zu beheben. Bei welcher checked Exception in der Java-API sollte das (immer) so sein?

 

[irgendjemand]

meiner ansicht nach zumindest bei allem was mit i/o *gleich welcher art* zu tun hat um z.b. datenverlust zu vermeiden

 

[tfa]

Wie kann man die Ausnahme beheben, wenn
* die Festplatte voll ist?
* man keine Schreibrechte hat?
* die SQL-Datenbank einen Fehler meldet?
* das Daten-Encoding nicht unterstützt wird?
* das Datei-Format korrupt ist?

Gar nicht!
Du kannst das nur in eine hübsche Meldung verpacken und dem Anwender sagen, probier's irgendwie anders oder ruf die Hotline an.

 

[irgendjemand]

ich wusste garnicht das man datei-formate seit neustem auch bestechen kann *corrupt = kaputt ... hat mit koruption nichts zu tun* ...

der sinn hinter checked exceptions ist das man diese fangen MUSS ... um halt eine fehlermeldung zu erzeugen ...

unchecked exceptions werden bis zur VM durchgeworfen ... und wenn man nicht grad ne console im hintergrund offen hat bekommt man auch nicht mit das diese ausgelöst wurde ...

*oder wenn man in einer GUI-app in einen catch-block Exception.printStackTrace() schreibt*

 

[hdi]

der sinn hinter checked exceptions ist das man diese fangen MUSS ... um halt eine fehlermeldung zu erzeugen ...

Da die Anzeige einer Fehlermeldung aber kein wirklicher Fix ist, und du wohl in allen möglichen Checked Exceptions immer wieder nur "showDialog()" machen kannst, was den Code ziemlich aufbläht und nervt, hat sich eher der Trend entwickelt, dass man nur noch Runtime Exceptions wirft und einen Default Handler einrichtet, um dort einen Fehlerdialog anzuzeigen. Macht also den Code schlanker und du läufst trotzdem nicht Gefahr eine (auch Runtime-)Exception einfach zu verpassen. Zumindest hab ich das so aus einem FAQ-Beitrag einer unserer Mitglieder herausgelesen, und es macht imho auch Sinn.

edit: Da fällt mir auf besagter User ist tfa, zwei Posts unter mir Danke für deinen Post an dieser Stelle, durch dich weiß ich überhaupt dass es sowas Default Handler gibt.

 

[headnut]

foo() ist ja eine ganz normale Methode die du in einem fehlerfall aufrufst, wiso hast du hier im try eine weitere Methode die wirder irgendetwaswirft?

ich schnall das noch nicht ganz, aber ihr würdet in dem fall nicht jede exception in weiterwerfen und am ursprung des aufrufes abfangen?

* Und was meinst du mit LOGGER? was macht der

* Hast du den javavideokurs gemacht? da bin ich seeeehr viel am zuhören

public void foo() {
    try {
         methodeDieExceptionsWirft();
    }
    catch(Exception x) {    // FALSCH! Nicht alle Exceptions auf einmal fangen! 
                            // FALSCH! Exceptions nicht ignorieren!
    }
}
 
public void bar() {
    try {
         methodeDieExceptionsWirft();
    }
    catch(FileNotFoundException fnfex) {            // RICHTIG: konkrete Exceptions einzeln angeben
         myExceptionHandler.handleException(x);    
    }
    catch(SQLException sqlex) {                     
         sqlex.printStacktrace();                   // OK: Stacktrace auf Konsole ausgeben
         LOGGER.error(sqlex);                       // BESSER: Exception loggen
    }
    catch(ParseException pex) {
         throw new RuntimeException("unerwartete Exception", pex);  // OK: checked Exception in RTEx kapseln
    }
}

 

[GUI-Programmer]

Auch eine Möglichkeit, zumindest in den Testphasen des Programms mit Exceptions umzugehen:

try {
	// Code der eine Exception werfen könnte
} catch(Exception ex) {
	StackTraceElement[] stacktrace = ex.getStackTrace();
	StringBuffer buffer = new StringBuffer();
	for(int i=0; i<stacktrace.length; i++) {
		buffer.append(stacktrace[i]+"\n");
	}
	buffer.deleteCharAt(buffer.length()-1);
	System.err.println(buffer);
	JOptionPane.showMessageDialog(null, buffer.toString(), ex.toString(), JOptionPane.ERROR_MESSAGE);
}

So wird das Programm zumindest nicht abgebrochen.

 

[André Uhres]

Der Link zu dem FAQ-Eintrag von tfa über Exceptions steht übrigens auch in seiner Signatur .

 

[headnut]

ja den hab ich auch gelesen, nur haben sich hal ein paar fragen aufgetan..

GUI-Programmer, danke vielmals für die beiden programme Dank diesen hb ich nun sogar die sache mit dem observer verstanden

Wenn du jetzt einwenig eine grössere GUI hast, mit mehreren viewer, würderst du für jeden view einen controller und ein model machen? Oder halt einwenig angemessen...

 

[Gast2]

Auch eine Möglichkeit, zumindest in den Testphasen des Programms mit Exceptions umzugehen:

try {
	// Code der eine Exception werfen könnte
} catch(Exception ex) {
	StackTraceElement[] stacktrace = ex.getStackTrace();
	StringBuffer buffer = new StringBuffer();
	for(int i=0; i<stacktrace.length; i++) {
		buffer.append(stacktrace[i]+"\n");
	}
	buffer.deleteCharAt(buffer.length()-1);
	System.err.println(buffer);
	JOptionPane.showMessageDialog(null, buffer.toString(), ex.toString(), JOptionPane.ERROR_MESSAGE);
}

So wird das Programm zumindest nicht abgebrochen.

Aber du willst doch in deiner DAO Logik oder Business Logik oder sonst wo keine UI Abhänigkeiten.
Darum eben in RuntimeException kapseln und dann auf UI-Ebene einen ExceptionHandler oder sonst wie ausgeben.

Der einzige Nachteil den ich an den RuntimeException sehe, ist dass man bei manchen Frameworks nicht immer weiß welche Exception genau gewerfen wird.

 

[GUI-Programmer]

Wenn du jetzt einwenig eine grössere GUI hast, mit mehreren viewer, würderst du für jeden view einen controller und ein model machen? Oder halt einwenig angemessen...

Das kommt ganz auf das Programm an. Wenn es sich als sinnvoll erweist, dann ja.

Hier mal ein weiteres Programm von mir, das etwas größer ist und nach MVC aufgebaut ist:
Google Mail Desktop Application

Außerdem beinhaltet auch Figuren Zeichner MVC.

 

[headnut]

Das mailprogramm muss ich in aller ruhe anschauen, dies ist relativ heftig... was ich waber bereits gesehen habe ist, dass du die view komplett protected machst, wiso?

Ich werde jetzt dein kleines MVC mal genau ansehen, damit ich die observer sache kapiere...

Wenn jetzt bei deinem mvc besipiel noch ein thread dazu laufen würde der per TCP daten empfängt, wie würdest du diese der GUI schicken? Indem du sie direkt in das Model schreibst und danach dem GUI weiterleitest?

 

[GUI-Programmer]

Das mailprogramm muss ich in aller ruhe anschauen, dies ist relativ heftig... was ich waber bereits gesehen habe ist, dass du die view komplett protected machst, wiso?

Ist vielleicht etwas "faul" von mir, aber somit kann der Controller auf direkten Weg auf Componenten der View zugreifen. Beispiel (in Controller):

view.lblInfo.setText("Die neue Information");

Anstatt für jede Komponente, auf die im Controller zugegriffen werden sollte, getter und setter zu schreiben.

Folglich könnte der Aufbau vom Controller (entgegen der Meinung von bERt0r) auch so aussehen:

public class Controller implements ActionListener
{
	private Model model;
	private View view;
	
	public Controller(Model model, View view)
	{
		this.model = model;
		this.view = view;
	}
	
	@Override
	public void actionPerformed(ActionEvent evt)
	{
		
		if (evt.getSource().equals(view.btnCalculate))
		{
			model.calculate(300);
		}
	//..
	}
	//...
}

Außerdem beinhaltet auch Figuren Zeichner MVC.

Muss mich entschuldigen. Sehe garade, dass darin gar kein Model vorkommt (Wozu auch!). Ist daher wohl ehr "VC"

Wenn jetzt bei deinem mvc besipiel noch ein thread dazu laufen würde der per TCP daten empfängt, wie würdest du diese der GUI schicken? Indem du sie direkt in das Model schreibst und danach dem GUI weiterleitest?

TCP Daten empfangen: Im Model, und zwar ohne Thread
Im Controller dann: Thread, in welchem die Methode vom Model aufgerufen wird.

 

[headnut]

Ich glaube ich muss für mich ein System finden das mir passt. Wenn ich deine Vorschläge so ansehe gehen die alle in eine richtung aber in der ausführung sind sie sehr unterschiedlich

Ich denke für den anfang mach ich die sache private mit getter und setter oder wie du oben über den event...

Ich bau dies nun auf und werd mich wahrscheinlich nochmals melden.

Danke

 

[Gast2]

Ich glaube ich muss für mich ein System finden das mir passt. Wenn ich deine Vorschläge so ansehe gehen die alle in eine richtung aber in der ausführung sind sie sehr unterschiedlich

Ich denke für den anfang mach ich die sache private mit getter und setter oder wie du oben über den event...

Ich bau dies nun auf und werd mich wahrscheinlich nochmals melden.

Danke

Du kannst deine Listener (z.B. ActionListener) auch einfach als anonyme Klassen hinzufügen. Dann benötigst du keine getter/setter in der View und dein Code wird schlanker.

 

[GUI-Programmer]

Du kannst deine Listener (z.B. ActionListener) auch einfach als anonyme Klassen hinzufügen. Dann benötigst du keine getter/setter in der View und dein Code wird schlanker.

Da gebe ich dir völlig Recht. Nur das es dann halt kein MVC mehr ist, was hier wahrscheinlich schon sehr sinnvoll wäre, was der TO auch erkannt hat.

 

[Gast2]

Da gebe ich dir völlig Recht. Nur das es dann halt kein MVC mehr ist, was hier wahrscheinlich schon sehr sinnvoll wäre, was der TO auch erkannt hat.

Sagt wer?
MVC gibt es in viele Formen und viele Ausprägungen, nur weil du anonyme Listener (Controller) machst ist es immer noch MVC...
Oder nenn es MVP wie du magst
http://blog.vuscode.com/blogs/blogs...nterMVPVSModelViewControll_1327B/image_15.png

 

[GUI-Programmer]

Oder nenn es MVP wie du magst
http://blog.vuscode.com/blogs/blogs...nterMVPVSModelViewControll_1327B/image_15.png

Schon eher. Denn MVC beinhaltet die strikte Trennung von den Bestandteilen, und anonyme Klassen befinden sich ja direkt zwischen den ganzen grafischen Code und das ist meiner Meinung nach nicht getrennt.

 

[Gast2]

Schon eher. Denn MVC beinhaltet die strikte Trennung von den Bestandteilen, und anonyme Klassen befinden sich ja direkt zwischen den ganzen grafischen Code und das ist meiner Meinung nach nicht getrennt.

Wie gesagt es gibt mehere Ausprägungen und Interpretationen von MVC...
Und da die Listener immer UI Toolkit abhängig sind macht diese strikte Trennung imho wenig Sinn (gibt natürlich Ausnahmen), weil du kannst Sie nicht wiederverwenden in anderen UI Toolkits und bläht es den Code sehr auf (z.b. getter/setter usw).
Außerdem ist es einfach umständlich jedes mal eine neue Klasse dafür anzulegen.

Klar sollte sein wenn man anonyme Klassen benutzt da nicht jede Menge Code drin stehen sollte.
Ich favorisiere immer noch sowas in der Art:

 

[Gast2]

Mit EventBus ist es auch ganz nett und relativ übersichtlich mit wenig Code
Einführung in den EventBus

 

[GUI-Programmer]

@SirWayne: Ich muss dir zustimmen: Beide Möglichkeiten der Implementierung sind sehr sinnvoll, ABER dennoch kein MVC.


P.S. Bevor du jetzt wieder versuchst mir das Gegenteil zu beweisen, warte doch bitte wenigsten auf die Meinungen von mind. 3 weiteren Benutzern. DANKE

 

[Gast2]

Du kannst es auch halten wie du willst, aber du hast mir bis jetzt noch kein Argument für deine Variante geliefert...

 

[GUI-Programmer]

Du kannst es auch halten wie du willst, aber du hast mir bis jetzt noch kein Argument für deine Variante geliefert...

Bei meiner Variante sind "die Controller" nicht in der View - Klasse, sowie bei dir. Wie bereits gesagt, manchmal kann das durchaus sinvoll sein. Beispiel: Wenn ein JPanel erscheint soll der Benutzer die Information bekommen, auf welchen Panel/Bildschirm er sichgerad befindet:

//...
JPanel pnlIrgendeins = new JPanel();
pnlIrgendeins.addComponentListener(new ComponentAdapter() {
    public void componentShown(ComponentEvent evt) {
        lblAnzeig.setText("Sie befinden sich auf Bildschirm 3");
        //und/oder:
        System.out.println("Sie befinden sich auf Bildschirm 3");
    }
});

Doch wie bereits gesagt: Anonyme Controller - Klassen in View != MVC, weil MVC = Trennung von Model, View & Controller

So, jetzt warte aber doch bitte mal auf die Meinungen von anderen!!!!!!

 

[Gast2]

So, jetzt warte aber doch bitte mal auf die Meinungen von anderen!!!!!!

Wenn dir was nicht passt, dann antworte einfach nicht mehr, aber ich lasse mir von dir bestimmt nicht sagen auf was ich warten muss!!! Schreibs einfach noch größer vielleicht wirkts dann!!!

Oder einfach Suchfunktion benutzen dann siehst du doch die ganzen Varianten was es schon gab
http://www.java-forum.org/allgemeines/91829-mvc.html

 

[GUI-Programmer]

@SirWayne: Ok, bin ja schon ruhig. Warten wir mal ab.

 

[maki]

Was ist den hier los?
Bitte mal alle locker machen

Ansonsten möge man sich die sog. "Definition" von MVC mal ansehen und feststellen dass letztere entweder nur wischi-waschi ist oder nun anders als in den 80er interpretiert wird.. MVC ist auch mehr ein grobes Paradigma und von der konkreten Viewtechnologie anhängig,

Auch sollte man sich mal MVP, Passive View, ViewController etc. pp. mal ansehen.

 

[Gast2]

Bitte mal alle locker machen

Bin total locker, lass mir nur auf so unverschämte art und weise nicht sagen, wann ich schreiben darf, soll, will =)

Ansonsten möge man sich die sog. "Definition" von MVC mal ansehen und feststellen dass letztere entweder nur wischi-waschi ist oder nun anders als in den 80er interpretiert wird.. MVC ist auch mehr ein grobes Paradigma und von der konkreten Viewtechnologie anhängig,

Auch sollte man sich mal MVP, Passive View, ViewController etc. pp. mal ansehen.

Jo kann man ja weiter mit machen MVA usw.,
Seh ich auch so gibt eben mehrere Interpretationen.

 

[GUI-Programmer]

Bin total locker, lass mir nur auf so unverschämte art und weise nicht sagen, wann ich schreiben darf, soll, will

So war das ja auch nicht gemeint. Wollte damit lediglich unsere Diskussion stoppen und mir weitere Meinungen anhören, was jetzt ja auch passiert ist.

Jo kann man ja weiter mit machen MVA usw.,
Seh ich auch so gibt eben mehrere Interpretationen.

Seh ich ja genauso! Ich selbst verwende ja manchmal (wenn auch sehr selten) diese anonyme Klassen. Und das MVC da wirklich so einen großen Spielraum für Interpretationen lässt war, gestehe ich ja, mir wirklich nicht bewusst.

Somit ist die Diskussion nun hoffentlich beendet, bzw. es geht wieder um den Thread vom TO.