Gibt es Performanceeinbußen durch exception handling?

jule37

ich habs inzwischen rausgenommen. aber damit besser nachvollziehbar wird was ich vorhatte zeig ich mal eben nen auszug aus der klasse:

package system.application;

import ...

public class Application {

	private static Application INSTANCE = null;
	protected ...;

	private Application(String title) {
		...;
	}

	public static Application createInstance(String title) {
		if(INSTANCE == null) {
			INSTANCE = new Application(title);
			return INSTANCE;
		}
		return null;
	}

	public static Application getInstance() {
		return INSTANCE;
	}

    ...
}

also ich hab da dieses singleton Application, dass meine applikation repräsentiert, sprich den prozess. das wird halt benötigt, da meine applikation ein virtuelles windowing subsystem hat, an das systemnachrichten usw verteilt werden müssen und man soll in der lage sein, auf statischem wege an die instanz der applikation heranzukommen. das ganze soll das kernstück eines frameworks werden.

ich hatte nun vor in der methode getInstance() eine spezielle exception zu werfen, falls keine instanz vorhanden ist, da einfach nur ein nullpointer, so dachte ich, für diesen speziellen fall nicht aussagekräftig genug wäre. wie gesagt, ich versuche das hier so zu schreiben, damit andere leute es benutzen können, deshalb dieser gedanke.

falls jemand von euch mit sowas erfahrung hat, würde es mich interessieren, ob mein ansatz programmiertechnisch sinnvoll ist (also beide sachen - die idee mit der exception und das applikations singleton). ich find ihn zwar gut, aber ich bin noch nicht sehr erfahren mit komplexen projekten.
wäre toll ein wenig anregung zu bekommen und danke auch für eure antworten auf die erste frage

Badestrand

Du könntest die createInstance- und getInstance-Methoden auch zusammenfassen

public static Application getInstance(String title) {
        if(INSTANCE == null)
            INSTANCE = new Application(title);
        return INSTANCE;
    }

Oh doch nicht, Schwachsinn. Ist natürlich komplizierter, da du den Titel ja mitgeben musst... Sorry, meine Antwort quasi streichen

edit2: Du könntest fordern, dass "createInstance" immer am Programmstart aufgerufen wird. Wenn du das dann so forderst, ist imho ein assert in "getInstance" (für INSTANCE==NULL) eine gute Lösung.

Gregor

tfa schrieb:

Gregor schrieb:

Wenn eine RuntimeException fliegt, dann heißt das eigentlich immer, dass Du einen Bug in Deine Software eingebaut hast.

Das gilt allerdings nur für die Standard-Java-API. Modernere Libs und Frameworks verzichten völlig auf checked Exceptions und werfen nur noch RuntimeExceptions, die man natürlich ggf. fangen und behandeln muss.

Gib mal ein Beispiel. Welches Framework meinst Du und was werden da für Exceptions geworfen.

Gregor schrieb:

Gib mal ein Beispiel. Welches Framework meinst Du und was werden da für Exceptions geworfen.

Hibernate, wobei ich das nicht als gutes Framework bezeichnen würde, da daran schon viel zu oft was geändert wurde und man dann dauernd seinen Code ändern darf...

jule37 was soll dieses INSTANCE Ding sein, bei dem man irgendwie nur einmal den Titel angeben kann? Soll jede Applikation nur ein einziges Fenster mit Titel haben dürfen oder für was ist das gut?

Gregor

farbenkombination schrieb:

Gregor schrieb:

Gib mal ein Beispiel. Welches Framework meinst Du und was werden da für Exceptions geworfen.

Hibernate, wobei ich das nicht als gutes Framework bezeichnen würde, da daran schon viel zu oft was geändert wurde und man dann dauernd seinen Code ändern darf...

Und was für Exceptions betrifft das da? In welchem Zusammenhang werden die geworfen?

Z.B.:
http://www.hibernate.org/hib_docs/v3/api/org/hibernate/exception/SQLGrammarException.html

Klick dich einfach mal durch die ganzen Exceptions durch und wenn du den Eindruck hast, dass es irgendwie "ungewöhnlich" ist, bist du nicht allein.

Gregor

farbenkombination schrieb:

Z.B.:
http://www.hibernate.org/hib_docs/v3/api/org/hibernate/exception/SQLGrammarException.html

Klick dich einfach mal durch die ganzen Exceptions durch und wenn du den Eindruck hast, dass es irgendwie "ungewöhnlich" ist, bist du nicht allein.

Naja, die würde ich vermutlich auch als RuntimeException realisieren. Ist ja praktisch soetwas ähnliches wie eine IllegalArgumentException. Für das, was Dein Programm an SQL-Code produziert, ist Dein Programm selbst verantwortlich. Wenn Code produziert wird, der nicht funktioniert, dann ist das ein Bug im Programm.

Aber ich werde mir die ganzen Exceptions da mal angucken. Ich bin gespannt, was man da so findet.

Das tolle daran ist ja auch, das es bei Hibernate nomral Exceptions gab die in ner anderen Version plötzlich zu Runtime Exceptions wurden. Ganz zu scheigen von den HQL Syntaxänderungen...

DEvent

Gregor schrieb:

farbenkombination schrieb:

Z.B.:
http://www.hibernate.org/hib_docs/v3/api/org/hibernate/exception/SQLGrammarException.html

Klick dich einfach mal durch die ganzen Exceptions durch und wenn du den Eindruck hast, dass es irgendwie "ungewöhnlich" ist, bist du nicht allein.

Naja, die würde ich vermutlich auch als RuntimeException realisieren. Ist ja praktisch soetwas ähnliches wie eine IllegalArgumentException. Für das, was Dein Programm an SQL-Code produziert, ist Dein Programm selbst verantwortlich. Wenn Code produziert wird, der nicht funktioniert, dann ist das ein Bug im Programm.

Aber ich werde mir die ganzen Exceptions da mal angucken. Ich bin gespannt, was man da so findet.

Das Problem ist das eine RuntimeException nicht auf die Lebenszeit deines Programms andeutet, sondern auf die JavaVM-Runtime. Ausserdem fliegt eine RuntimeException nur wenn du einen schwerwiegenden Bug in deinem Programm hast, wie das Zugreifen auf eine ungueltige Referenz (NullPointerException), EmptyStackException, usw.

Das sind alles Exceptions die die JavaVM wirft, um anzuzeigen das du einen Bug in deinem Programm hast. Deswegen heist es auch NullPointerException und nicht NullRefernceException, weil eben die JavaVM auf einen null-Pointer zugreift.

Keine API sollte irgendwas von RuntimeException ableiten, also niemals neue NullPointer-Exception deklarieren.

Der einzige Grund, wieso es Hibernate macht, ist es, weil alle RuntimeExceptions unchecked sind.

jule37

farbenkombination schrieb:

...
jule37 was soll dieses INSTANCE Ding sein, bei dem man irgendwie nur einmal den Titel angeben kann? Soll jede Applikation nur ein einziges Fenster mit Titel haben dürfen oder für was ist das gut?

es ist die applikation an sich. es enthält das fenster (JFrame), wovon es nur eins geben darf, es enthält einen eigenen event stack, der events (java.awt.InputEvent und dessen subklassen) an das virtuelle windowing subsystem verteilt u.v.m., wobei die erstgenannten dinge im moment die wichtigsten sind.
ich habe mich halt dazu entschieden es so zu implementieren, da es pro prozess nur eine applikation geben darf (und damit nur ein fenster, da fullscreen exclusive und nur einen event stack für das subsystem etc). es ist an mehreren stellen erforderlich auf die in Application enthaltenen objekte zuzugreifen (windowing subsystem muss seine events vom stack holen), aber (imo) völlig unsinnig, dieses applikationsobjekt an alle anderen objekte im konstruktor als parameter zu übergeben.
schwierig präzise auf den punkt zu formulieren, was ich meine, aber ich glaube jetzt ist das wesentliche gesagt

was mich nun interessiert: ist das konzept gut oder eher mangelhaft designed? wenn jemand mit sowas erfahrung hat wäre es toll nen tip zu kriegen. ist ja nicht immer so einfach die entscheidung für was man globale objekte hat und für was bloß parameter.

gruß & danke

edit:
zur anderen diskusion: ist es nicht so, dass exceptions auschließlich zur laufzeit auftreten (deshalb ja überhaupt der notwand des exception handlings)? damit wäre doch die bezeichnung RuntimeException völliger unsinn(?)

Vevusio

erstens, zu dem singleton design von der application klasse, ich hätte es auch so gemacht

objekte die von denen man eben nur eine instanz braucht und die zusätzlich noch während dem ganzen programm regelmäßig benötigt werden und deswegen sowieso dauernd existieren solange das programm läuft sind finde ich perfekte kandidaten für singleton klassen

zu den exceptions

erstmal ganz allgemein, man kann finde ich nicht sagen "exceptions sind besser als rückgabewerte"; auch nicht dass sie schlechter sind

man muss sich einfach überlegen was in welchen situationen am ehesten geeignet ist

wenn ich beispielsweise eine methode habe welche ein element in eine liste einfügt in der jedes element nur 1 mal vorkommen darf kann man durchaus anstatt einer ElementAlreadyContainedException einfach den void rückgabewert auf boolean zu ändern und true/false je nachdem ob es eingefügt werden konnte zurück zu geben
entsprechend bei der suchmethode null als rückgabewert zurückgeben statt einer exception

ich finde beides ist eine gute lösung und es kommt einfach auf gewohnheit und persönliche präferenzen an wie man es löst, möglicherweise will man ein kleines programm zum prototyping oder einfach so zum lernen von etwas neuemm oder irgend ein tool programmieren und macht es mit eher wenigen exceptions oder man arbeitet an etwas großem wo man viel wert auf sicherheit etc legt und entschließt sich eher vorwiegend exceptions zu verwenden in kombination mit einem logging mechanismus in dem konstruktor der exceptions

gerade bei methoden die etwas initialisieren bzw viele verschiedene sachen schief gehen können sind exceptions viel nützlicher weil sie mir mehr sagen als [Alles OK? TRUE/FALSE] sondern ich x verschiedene exceptions bekommen kann wo der typ der exceptions allein schon sagt was passiert ist + messages, stack trace usw.

ok das mal dazu, performance mäßig würde ich mir absolut keine gedanken machen, bottlenecks liegen nicht in so sachen wie exceptions oder ob man jetzt pre oder postincrement ++ macht und diesen ganzen sachen die man von vorwiegend c und c++ programmierern dauernd hört

und zu RuntimeExceptions
in c++ ist jede exception eine runtime exception, in java gibt es ka.. ich weiss nicht wie das heisst ich glabe "checked exceptions" oder so, das bedeutet einfach dass die funktion in ihrer definition explizit sagt throws ThisAndThatException und man muss dann auf diese exception checken mit einem try-catch

wo man checked exceptions und wo man runtime exceptions verwenden sollte ist dann wieder so eine sache wo man sich halt überlegen muss was man will

runtimeexceptions in java sind halt beispielsweise stack overflow (rekursive methode falsch programmiert oder zu tief zb) oder array index out of bound

ich meine ich will nicht jedes mal wenn ich ein array benutze einen try catch block drum herum machen weil ich ja vielleicht in meiner for schleife die von 0 bis array.length geht auf einen ungültigen array index zugreife
oder um eine getter methode eine try/catch stackoverflow exception abfangen progbieren usw usw

dafür sind die halt gut, aber ich will schon einen benutzer dazu zwingen dass er eine LoadImageFile methode in einem zeichenprogramm oder so mit try/catch aufruft weil er wohl irgendwie etwas ausgeben möchte wenn der user versucht ein *.mp3 aufzumachen

runtime exceptions sind halt mehr so "assert" sachen, so wie

if(oh mein gott das darf niemals passieren)
    throw new NoobException("NOOB!"); //<- runtime exception

tfa

Gregor schrieb:

farbenkombination schrieb:

Gregor schrieb:

Gib mal ein Beispiel. Welches Framework meinst Du und was werden da für Exceptions geworfen.

Hibernate, wobei ich das nicht als gutes Framework bezeichnen würde, da daran schon viel zu oft was geändert wurde und man dann dauernd seinen Code ändern darf...

Und was für Exceptions betrifft das da? In welchem Zusammenhang werden die geworfen?

Alle Hibernate-Exceptions sind unchecked - und das ist auch gut so.
Als zweites großes Framework, das auf checked Exceptions verzichtet, ist Spring zu nennen.
Das Konzept der checked Exceptions in Java hat sich als nicht besonders brauchbar erwiesen. Deswegen sollte man sie nicht verwenden, wenn man selbst API entwirft.

Gregor

tfa schrieb:

Das Konzept der checked Exceptions in Java hat sich als nicht besonders brauchbar erwiesen. Deswegen sollte man sie nicht verwenden, wenn man selbst API entwirft.

Der Formulierung widerspreche ich einfach mal. Checked Exceptions haben genauso eine Berechtigung wie unchecked Exceptions. Aber ein anderes Anwendungsgebiet. Es gibt natürlich wenige Stellen, an denen checked Exceptions angebracht sind. Aber es gibt solche Stellen.

DEvent

Gregor schrieb:

tfa schrieb:

Das Konzept der checked Exceptions in Java hat sich als nicht besonders brauchbar erwiesen. Deswegen sollte man sie nicht verwenden, wenn man selbst API entwirft.

Der Formulierung widerspreche ich einfach mal. Checked Exceptions haben genauso eine Berechtigung wie unchecked Exceptions. Aber ein anderes Anwendungsgebiet. Es gibt natürlich wenige Stellen, an denen checked Exceptions angebracht sind. Aber es gibt solche Stellen.

Nenn doch bitte diese Stellen.

Gregor

DEvent schrieb:

Nenn doch bitte diese Stellen.

Jede Stelle, an der bei völlig korrekten Programmen unverhersehbare Ereignisse auftreten können, die eine Reaktion des Programms erfordern. Der IO-Bereich und die Netzwerkkommunikation sind diesbezüglich Paradebeispiele. Aber es kann ja auch sein, dass solche Fälle in Anwendungsgebieten auftreten, die nichts mit der Standardbibliothek zu tun haben.

tfa

Nein, auch bei solchen Stellen sind unchecked Exceptions vorzuziehen.
Gründe dafür gibt es genug.

http://radio.weblogs.com/0122027/stories/2003/04/01/JavasCheckedExceptionsWereAMistake.html
http://www.mindview.net/Etc/Discussions/CheckedExceptions
http://www.mail-archive.com/hibernate-devel@lists.sourceforge.net/msg04343.html

Vor kurzem gab es hierzu auch eine längere Diskussion. Benutz die Suche.

tfa

jule37 schrieb:

zur anderen diskusion: ist es nicht so, dass exceptions auschließlich zur laufzeit auftreten (deshalb ja überhaupt der notwand des exception handlings)? damit wäre doch die bezeichnung RuntimeException völliger unsinn(?)

Natürlich werden alle Exceptions zur Laufzeit geworfen. RuntimeExceptions heißen deswegen so, weil sie automatisch von der Laufzeitumgebung erzeugt werden, um sich z.B. vor Nullpointer-Dereferenzierung oder falschem Class-Casting zu schützen.
Die anderen Exceptions werden eher programmatisch (also durch throw new Exception()) erzeugt und geworfen.

Gregor

tfa schrieb:

Nein, auch bei solchen Stellen sind unchecked Exceptions vorzuziehen.
Gründe dafür gibt es genug.

http://radio.weblogs.com/0122027/stories/2003/04/01/JavasCheckedExceptionsWereAMistake.html
http://www.mindview.net/Etc/Discussions/CheckedExceptions
http://www.mail-archive.com/hibernate-devel@lists.sourceforge.net/msg04343.html

Vor kurzem gab es hierzu auch eine längere Diskussion. Benutz die Suche.

Es ist ja nicht so, dass meine Meinung völlig aus der Luft gegriffen ist. Ich kann Dir auch einige Quellen nennen, in denen für meine Ansicht argumentiert wird. Lies zum Beispiel mal "Effektiv Java programmieren". Da steht ne ganze Menge zu diesem Thema drin.

ich bin ja mal gespannt wie es in ein paar Jahren mit Exceptions aussieht, oder obs dann schon was besseres gibt.

tfa

Gregor schrieb:

Es ist ja nicht so, dass meine Meinung völlig aus der Luft gegriffen ist. Ich kann Dir auch einige Quellen nennen, in denen für meine Ansicht argumentiert wird. Lies zum Beispiel mal "Effektiv Java programmieren". Da steht ne ganze Menge zu diesem Thema drin.

Dann nenn mal einige aktuelle Quellen.
Das Buch von Josh Bloch hab ich zufällig im Regal stehen. Er beschreibt ziemlich genau das ursprüngliche von Sun entworfene Exception-Konzept, was verständlich ist, wurde das Buch doch in Kooperation mit Sun Microsystems herausgegeben, wo Bloch auch angestellt war.
Außerdem ist der Text aus dem Jahr 2001. Damals war die Auffassung noch nicht so verbreitet, dass checked Exceptions schlecht seien (HibernateException war z.B. noch checked).
Vor 7 Jahren habe ich da auch noch dran geglaubt, aber mittlerweile hat sich meine Meinung geändert.

Aber völlig falsch sind Blochs Tips trotzdem nicht:

Effektiv Java programmieren schrieb:

Vermeiden Sie den unnötigen Einsatz von geprüften Ausnahmen

Es scheint also doch ein Problem mit checked Exceptions zu geben?

Effektiv Java programmieren schrieb:

Geprüfte Ausnahmen für behebbare Situationen

Auch richtig. Ich behaupte, der Designer eines Frameworks oder API kann gar nicht entscheiden, ob eine Ausnahmesituation für den Verwender seines Codes behebbar ist oder nicht. In den allermeisten Fällen wird sie nicht behebbar sein - nach meiner Erfahrung.

Effektiv Java programmieren schrieb:

[Geprüfte Ausnahmen sind] gerechtfertigt, wenn die Ausnahmebedingung nicht durch korrekte Benutzung des APIs zu verhindern ist und außerdem die Programmierer, die das API benutzen, etwas Sinvolles tun können, wenn sie mit der Ausnahme konfrontiert werden. Wenn nicht beides zutrifft, dann ist eine geprüfte Ausnahme besser. Sie sollten sich fragen, wie der Programmierer die Ausnahme behandeln wird.

Und das ist häufig, die Exception zu ignorieren, zu loggen, weiterzuwerfen oder printStacktrace() aufzurufen. Mit Sicherheit nichts Sinnvolles.

Wenn du in einer (closed source) Individualsoftware durch selbstdefinierte checked Exceptions dich selbst zur Fehlerbehandlung zwingen willst, so ist das in Ordnung. Aber in wiederverwendbaren Bibliotheken (also auch der Standard-API) haben die nichts zu suchen.
Leider werden wir sie wohl nie wieder los.