Exceptionfreie Anweisungen in try-catch-Blöcke,

[Georgey]

Hallo allesamt,

ich hab in einem Buch einen Beispielcode gesehen und frage mich, ob man den try-catch-Block nicht einfach nur um die Anweisung Thread.sleep(DELAY) einfügen sollte.
Also von

public void run() 
	{
		try {
			for (int i = 1; i <= STEPS; i++) {
				ball.move(component.getBounds());
				component.repaint();
				Thread.sleep(DELAY);
			}
		}
		catch (InterruptedException exception) {
		}
	}

zu

public void run() 
	{
		for (int i = 1; i <= STEPS; i++) {
			ball.move(component.getBounds());
			component.repaint();
			
			try {
				Thread.sleep(DELAY);
			}
			catch (InterruptedException exception) {
			}
		}
	}

Denn schließlich wirft in diesem Code nur die Thread.sleep() Anweisung eine mögliche Exception.
Wäre mein Beispiel so performanter? Wird überhaupt irgendwelcher Overhead verbraucht, wenn die 2 Anweisungen "ball.move(component.getBounds());" und "component.repaint();" im try mit aufgenommen werden?
Wenn ja, wie genau entsteht der Overhead? Indem die JRE quasi an jeder Anweisung im try-Block nach Exceptions "lauscht"?

Wenn man zu try-catch was googelt, findet man leider nie derart tiefergehende Informationen.

Danke für die Hilfe.

 

[Marco13]

Ich denke, mit performance hat das weniger zu tun. Vielmehr würde, wenn bei dem Thread.sleep etwas schiefgeht, dass ja 'STEPS' mal probiert. Bei der ersten Variante wird gleich die ganze Schleife abgebochen.

Man könnte IMHO also entweder sowas machen wie

    public void run() 
    {
        for (int i = 1; i <= STEPS; i++) {
            ball.move(component.getBounds());
            component.repaint();
            
            try {
                Thread.sleep(DELAY);
            }
            catch (InterruptedException exception) 
            {[b]
                Thread.currentThread().interrupt();
                return;[/b]
            }
        }
    }

oder das try/catch gleich um die ganze Schleife wickeln, die ann automatisch abgebrochen wird, wenn es kracht.

Schau dir auch mal [JavaSpecialists 056] - Shutting down threads cleanly an.

 

[CHE123]

hi,

die InterruptedException teilt dir mit, dass der Thread (von aussen) unterbrochen wurde und
aufhören soll - in deinem Code würde der Thread quasi weiterlaufen - das soll nicht sein!
Der Beispielcode passt und hat keinerlei negative Auswirkung auf die Performance.

g,
Christina

 

[Georgey]

Sorry, ich hab ein schlechtes Beispiel genommen. Stellen wir uns vor, dass die for-Schleifen weg wäre.

Also so:

public void run() 
	{
		try {	
			ball.move(component.getBounds());
			component.repaint();
			Thread.sleep(DELAY);
			}
		catch (InterruptedException exception) {
		}
	}

und mein abgewandeltes Beispiel:

public void run() 
	{
			ball.move(component.getBounds());
			component.repaint();
			
			try {
				Thread.sleep(DELAY);
			}
			catch (InterruptedException exception) {
			}
	}

Mir geht es hier überhaupt nicht um Threading. Das in den catch block ein Thread.currentThread().interrupt(); empfohlen ist, ist mir gerade auch nicht wichtig.

Meine Fragen sind wie zuvor dieselben:

Wäre mein Beispiel (das letzte) so performanter? Wird überhaupt irgendwelcher Overhead verbraucht, wenn die 2 Anweisungen "ball.move(component.getBounds());" und "component.repaint();" im try mit aufgenommen werden?
Wenn ja, wie genau entsteht der Overhead? Indem die JRE quasi an jeder Anweisung im try-Block nach Exceptions "lauscht"?

Damit ihr mich nicht missversteht: Ich bin kein absoluter Neuling. Ich will mehr vom Interna verstehen.

 

[Marco13]

Wenn man's genauer wissen will, steht dazu auf VM Spec Compiling for the Java Virtual Machine oder VM Spec Java Programming Language Conceptsein bißchen was.

Als Beispiel: Wenn man das hier compiliert

class TryTest
{

    private static void dummy()
    {
    }

    public static void first()
    {
        try
        {
            dummy();
            Thread.sleep(100);
        }
        catch (Exception e) {}
    }

    public static void second()
    {
        dummy();
        try
        {
            Thread.sleep(100);
        }
        catch (Exception e) {}
    }
}

Und das dann mit
[c]javap -c TryTest[/c]
decompiliert, erhält man

Compiled from "TryTest.java"
class TryTest extends java.lang.Object{
TryTest();
  Code:
   0:   aload_0
   1:   invokespecial   #1; //Method java/lang/Object."<init>":()V
   4:   return

public static void first();
  Code:
   0:   invokestatic    #2; //Method dummy:()V
   3:   ldc2_w  #3; //long 100l
   6:   invokestatic    #5; //Method java/lang/Thread.sleep:(J)V
   9:   goto    13
   12:  astore_0
   13:  return
  Exception table:
   from   to  target type
     0     9    12   Class java/lang/Exception


public static void second();
  Code:
   0:   invokestatic    #2; //Method dummy:()V
   3:   ldc2_w  #3; //long 100l
   6:   invokestatic    #5; //Method java/lang/Thread.sleep:(J)V
   9:   goto    13
   12:  astore_0
   13:  return
  Exception table:
   from   to  target type
     3     9    12   Class java/lang/Exception


}

Wie man sieht ist der bytecode in beiden Fällen der gleiche. Lediglich der Bereich, in dem Exceptions abgefangen werden, ist ein anderer. Man kann davon ausgehen, dass das keinen Performanceunterschied macht. Wenn der JIT nochmal drüberläuft, könnte das zwar theoretisch anders sein, aber solche Dinge wie Deep dive into assembly code from Java | Java.net nachzuvollziehen überlasse ich dann mal anderen...

 

[musiKk]

Durch größere try-Blöcke entsteht kein weiterer Overhead. Die Bereiche, die ein try-Block schützt, sind in einer Tabelle abgelegt, die konsultiert werden kann, wenn eine Exception auftritt; dort steht auch, wo der catch-Block zu finden ist. Selbiger wird im Erfolgsfall per goto übersprungen. So machts zumindest javac von Sun.

edit: Ich dachte mir schon, dass Marco13 hier auch noch ordentlich was beitragen würde...

 

[Georgey]

Okay danke, damit ist meine Neugierde mal hinreichend getilgt. Bis in den Assemblercode will ich lieber mal nicht gehen

Danke.