Nov 09

Im SCJP wird auch zwischen geeigneter und ungeeigneter/ nicht zweckmäßiger Nutzung unterschieden. In diesem Zusammenhang möchte ich die unangebrachte Nutzung von Assertions vorstellen:

  1. Nochmal zur Errinerung: Assertions sind Codeüberprüungen, die bei false zu einem Programabbruch führen. Natürlich können diese auch mittels try/catch/finally abgefangen werden, es ist aber nicht zweckmäßig.
  2. Assertions sollten nicht in mit public deklarierten Methoden verwendet werden, da nicht immer klar sein kann, woher diese Methode aufgerufen wird und welche Werte benötigt und genutzt werden. Aufrufe innerhalb von privaten Methoden sind jedoch überschaubar und deswegen zweckmäßig.
  3. Nochmal zur Erinnerung: Assertions können jederzeit ein- und ausgeschaltet werden. Deswegen sollten diese nicht für Werte, die dem Aufruf des Programmes mitgegeben wurden, benutzt werden. Hier sind andauernd geworfene Exceptions passender.
  4. Anweisungen/ Schleifen, die niemals erreicht werden sollen, sollten vorher, aber nicht in der Anweisung/ Schleife per Assertion überprüft werden
  5. Assertions sollten das Programm im selben Status verlassen, in dem es vor der Überprüfung war. Deswegen ist es wichtig, Seiteneffekte  zu vermeiden. Assertions sollten deswegen nie Änderungen/ Deklarationen von Variablen abfangen.

Un-Zweckmäßiger gebraucht bedeutet nicht un-legitime Programmierung. Alle genannten Beispiele compilieren einwandfrei und lassen sich ebenso ausführen.

Es bedeutet lediglich, dass Assertions nicht in einer der genannten Arten gebraucht werden sollten.

Tagged with:
Nov 07

Heute will ich noch etwas tiefer in das An- und Ausschalten von Assertions einsteigen.

java -ea -dsa Test

schaltet Assertions in System-Klassen aus, während

java -esa Test

Assertions nur in System-Klassen einschaltet.

Es  können z.B. auch nur für bestimmte packages Assertions an- oder ausgeschaltet werden:

java -ea -da x… Test

startet die Klasse Test mit angeschalteten Assertions; nur für das Package x und alle Sub-Packages sind Assertions ausgeschaltet.

java -ea -da x.y Test

startet in diesem Beispiel die Klasse Test mit angeschalteten Assertions; nur für das Package x.y sind Assertions ausgeschaltet.

java -ea -da x.y.Angestellter Test

startet die Klasse Test mit eingeschalteten Assertions, nur für die Klasse Angestellter im Package x.y sind Assertions ausgeschaltet.

Analog hierzu können auch nur bestimme Assertions eingeschaltet werden.

Tagged with:
Nov 05

Assertions werden während des Programmstarts eingeschaltet mit

java -ea <Pfad/Dateiname>

oder

java -enableassertions <Pfad/Dateiname>

Ausgeschaltet werden assertions mit

java -da <Pfad/Dateiname>

oder

java – disableassertions <Pfad/Dateiname>

In älteren Versionen (1.3 und früher) durfte noch der Variablenname assert verwendet werden, z.B.

int assert = 1;

oder

int assert = prüfe();

if (assert > 2) { // … }

Dies ist nun nicht mehr möglich. Sollte aber aus irgendeinem Grunde so ein Code doch compiliert werden, kann dies mit

javac -source 1.3 <Dateiname>

Hierfür muss die entsprechende Version natürlich auch intialisiert werden.

Tagged with:
Okt 17

Wie bereits besprochen, wird ein Programm mit

java <Dateiname> oder java <Option>  <Dateiname> gestartet.

Eine Option im Zusammenhang mit Assertions ist die Option -ea, mit der Assertions angeschaltet und somit benutzt werden. Das Gegenstück hierzu ist -da mit der Assertions wieder ausgeschaltet werden.

Mit java -help können weitere Optionen abgefragt werden.

Tagged with:
Okt 07

Bei Assertions gibt es zusätzlich die Möglichkeit, bei der Fehlerbehandlung noch einen Text auszugeben:

assert (a.PersNr > 0): “Dies ist ein zusätzlicher Text, welcher ausgegeben wird”;

führt also bei einer negativen a.PersNr zu

Exception in thread “main” java.lang.AssertionError: Dies ist ein zusätzlicher Text, welcher ausgegeben wird
at Angestellter.main(Angestellter.java:42)

auch können nach dem “:” noch Methoden aufgerufen werden, die aber zwingend einen Wert zurückgeben müssen um einen CompilerFehler zu vermeiden:

assert (a.PersNr > 0): Math.sqrt(144); // Wenn PersNr < 0 führe Methode Math.sqrt(144) aus und gebe das Ergebnis mit aus

ist demnach genauso gültig.

Tagged with:
Okt 05

Assertions Errors oder auch kurz Assertions sind Code-Überprüfungen. Wenn wir von folgenden Beispiel ausgehen:

Angestellter a = new Angestellter ();
Scanner s = new Scanner (System.in);
a.PersNr=s.nextInt();

s.close();

wurden früher falsche Werte so oder ähnlich überprüft:

if (a.PersNr > 0)

System.out.println(“ok”);

else

System.out.println(“nicht ok”);

mit Hilfe von Assertion-Errors kann man diese 4 Zeilen in einer Zeile zusammenfassen:

assert (a.PersNr > 0);

Nur, wenn die Assert-Kondition nicht erfüllt ist (also a.PersNr < 0) ist, wird ein AssertionError geworfen… und das beste daran ist; man kann diese sogar ein- und ausschalten!

In Eclipse kann dies z.B. im Menü File/Properties/Run-Debug-Settings/Edit/Reiter Arguments/ Feld VM-Arguments der Wert -ea (für Einschalten) bzw -da (für Ausschalten)gesetzt werden, auf die SCJP-relevante DOS-compilierung werde ich noch näher eingehen.

Tagged with:
Sep 27

Während ClassNotFoundException häufiger vorkommt als NoClassDefFoundError, ist es im Allgemeinen ein Indiz dafür, dass ein Java-Archiv im Klassenpfad fehlt.

Beim Aufruf der Klasse kommt es oft zu diesem Fehler. Mögliche Ursachen könnten folgende sein:

  • Die Klasse muss als public gesetzt sein. z.B. public class MeineKlasse
  • Die Classpath – Umgebungsvariable muss den Ordner der Klasse bzw. des Pakets enthalten.
  • Wenn die Klasse in einem Paket ist, muss sie überden Paketnamen aufgerufen werden, z.B. java paket.Klasse
  • Der Aufruf der Datei erfolgt ohne die Dateiendung “.class”
Tagged with:
Sep 25

Wenn der Stapelspeicher ausgeschöpft ist, wird ein StackOverflowError geworfen:

class Angestellter {


static void overflow () {

overflow();

}

public static void main(String args[]) {

overflow();

}

}

In diesem Falle wurde eine sich  immer wieder selbst aufrufende Methode definiert, die den Stapelspeicher ausschöpft.

Tagged with:
Sep 23

ExceptionInInitializerError wird ausgegeben, wenn die statische Initialisierung aufgrund einer Ausnahme fehlschlägt:

class Angestellter {


public static int H = new Integer(“Test”);
// “Test” kann nicht zum Integer geboxt werden


public static void main(String args[]) {

System.out.println(H);


}

}

java.lang.ExceptionInInitializerError
Caused by: java.lang.NumberFormatException: For input string: “start”
at java.lang.NumberFormatException.forInputString(Unknown Source)
at java.lang.Integer.parseInt(Unknown Source)
at java.lang.Integer.<init>(Unknown Source)
at Angestellter.<clinit>(Angestellter.java:18)
Exception in thread “main”

Achtung: Falls es sich nicht um eine statische Variable handelt, wird eine NumberFormatException geworfen

Tagged with:
Sep 15

Leider geht es jetzt wieder um graue Theorie; die Herkunft von Exceptions/ Errors; es gibt nämlich 2 große Herkunftsarten:

Java Virtual Machine (JVM) Exceptions/ Errors

Exceptions, die von der JVM geworfen werden, z.B.

  • ArrayIndexOutOfBoundsException
  • ClassCastException
  • NullPointerException
  • ExceptionInInitializerError
  • StackOverflowError
  • NoClassDefFoundError

programmatische Exceptions/ Errors (RuntimeExceptions)

Exceptions, die von dem Programmierer, geworfen oder verursacht werden, z.B.

  • IllegalArgumentException
  • IllegalStateException
  • NumberFormatException
  • AssertionError

So, und nun die schlechte Nachricht; diese sollte man im SCJP auseinanderhalten können. Ich werde die nächsten Tage hierauf näher eingehen.

Tagged with:
preload preload preload
http://www.wikio.de Blog Top Liste - by TopBlogs.de Blogverzeichnis - Blog Verzeichnis bloggerei.de Bloggeramt.de Software
Webbhotell Top Blogs