Gibt es Performanceeinbußen durch exception handling?

[jule37]

Hallo zusammen.
mal ganz hypothetisch: ich habe mich grad gefragt, ob die häufige verwendung von try{}catch(){} spürbar performance kostet. vor allem wenn man in callbacks mehrere verschachtelte try-blöcke hat. differenzierte fehlermeldungen sind wirklich sehr angenehm, aber bezahlt man sie mit schlechterer laufzeit? oder fällt das absolut nicht ins gewicht?
wenn jemand damit erfahrung hat, würde ich mich sehr freuen, daran teilhaben zu können

ich entwickle nämlich grad was, was flott sein muss, aber auch viele verschiedene lustige fehler schmeißen kann, wo es echt besser ist zu wissen, was genau passiert, als einfach nur java.lang.NullPointerException...

danke und einen schönen freitag noch

[byto]

Wenn keine Exception fliegt kostet es 0 Performance. Wenn eine Exception fliegt, kannst Du Dir ja die Laufzeit des Catch-Blocks angucken.

[mmmmmmmmmar]

Jetzt über sowas nachzudenken ist sowieso falsch.
http://en.wikipedia.org/wiki/Optimization_(computer_science)#When_to_optimize
Denk jetzt besser über richtige Algos und Datenstrukturen nach.

[Gregor]

byto schrieb:

Wenn keine Exception fliegt kostet es 0 Performance. Wenn eine Exception fliegt, kannst Du Dir ja die Laufzeit des Catch-Blocks angucken.

Das glaube ich nicht. Der Jitter wird bezüglich der Optimierungsmöglichkeiten eingeschränkt sein, wenn er es mit einem try-catch-Block zu tun kriegt. Vor allem wird er nicht über die Grenzen dieses Block hinweg optimieren können.

@jule37: Geh lieber sparsam mit try-catch-Blöcken um:

Solche Blöcke sind grundsätzlich nur für Exceptions gedacht, die keine RuntimeExceptions sind. Die NullPointerException, die Du erwähnst, ist aber eine. try-catch-Blöcke sind dazu gedacht, auf unvorhergesehene Situationen reagieren zu können. Die sind aber nicht zum Debuggen gedacht. Wenn eine RuntimeException fliegt, dann heißt das eigentlich immer, dass Du einen Bug in Deine Software eingebaut hast.

[Mehlvogel]

Der Perfomancenutzen wäre wenn überhaupt nur marginal und wahrscheinlich nicht messbar. Viel mehr wirst du mit geeigneten Datenstrukturen etc. rausholen. Gregor hat aber in soweit recht, dass Runtime Exceptions eher ein Zeichen von Fehlern im Programmcode sind, also nicht kein eigentliches Exception Handling benötigen sollten, sondern von vornerein verhindert werden müssen.

[tfa]

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.

[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.

[farbenkombination]

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?

[farbenkombination]

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.

[farbenkombination]

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.