Problem mit Exception

[derweise]

Hallo, hab folgende Testmethode: benutzerdefinierte Exception)

@Test(expected = OverflowException.class)
	public void testEnterWithOverflowException() throws OverflowException {
		queueList = new Queue_List();
		queueList.enter(2);
		queueList.enter(5);
		queueList.enter(1);
		queueList.enter(8);
		queueList.enter(2);
		queueList.enter(5);
		queueList.enter(1);
		queueList.enter(8);
	}

Die Methode soll eine Exception werfen, da die Anzahl der Elemente in der Queue das Limit(3, von 0 angefangen) übersteigt.

Die Enter-Methode sieht folgendermaßen aus:

	public void enter(Object value) throws OverflowException {
                //falls das limit der Queue noch nicht verdoppelt wurde
		if (elementCounter == limit && doubling == 0) {
			System.out.println("Limit reached for the first time, space has beed doubled now!");
			doubling=1;
			limit = limit * 2;
			throw new OverflowException("OverflowException");
		}
                //falls das limit der Queue schon mal verdoppelt wurde
		if (elementCounter >= limit && doubling == 1) {
			System.out.println("Limit reached for the last time, no more values can be saved!");
			throw new OverflowException("OverflowException");
		}
		else {..}
      } //ansonsten normales einfügen

Das PRoblem ist, dass nur die erste Exception nach dem einfügen von den ersten 3 Elementen geworfen wird, aber dann passiert komisches. Beim debugen verschwindet der Debugger in irgenwelchen lang.klassen so richtig tief rein und, wenn man wieder zurück kommt, sind die werte von limit und elementCounter auf Standard zurück gesetzt (3 und 0), obwohl sie ja vorher verändert wurden...

 

[derweise]

habs mal enter methode bisschen geändert:

@Override
	public void enter(Object value) throws OverflowException {
		// The list has not been initialized yet.
		if (elementCounter == 0) {
		 ...//einfaches hinzufügen
		} else {
			if (elementCounter == limit && doubling == 0) {
				System.out
						.println("Limit reached for the first time, space has beed doubled now!");
				doubling = 1;
				limit = limit * 2;
				enterValue(value);
				throw new OverflowException("OverflowException");
			}
			if (elementCounter >= limit && doubling == 1) {
				System.out .println("Limit reached for the last time, no more values can be saved!");
				throw new OverflowException("OverflowException");
			} else {
				enterValue(value);
			}
		}
	}
	private void enterValue(Object value){.....//fügt hinzu element}

Nachdem die Zahl 8 hinzugefüt wird, wird dann die Exception geworfen, aber dann kommt eine "InvocationTargetException"

 

[SlaterB]

von einem Debugger musst du nichts erzählen, falls du nicht dessen kompletten Quellcode mit dazupostest, auch wenn den dann keiner lesen würde,
ist ja schön und gut wenn der dir hilft, dessen Ausgaben dann aber zu untersuchen bringt nun gar nix, immer davon ausgehen dass er einfach alles falsch macht
(gar nicht mal unbedingt von sich aus, sondern auch in Verbindung mit deinem evtl. fehlerhaften Programm, falscher Bedienung, falscher Interpretation der Ergebnisse)

----------

das einzig sinnvolle ist hier ein laufendes Programm zu posten mit System.out.println()-Ausgaben der Zustände der Dinge an bestimmten Punkten,
bisher kann man (oder ich zumindest) aus deinen Angaben noch nicht allzu viel erkennen

wenn du weißt, dass in Zeile
> queueList.enter(8);
der Fehler auftritt,
dann schlage ich Code vor a la

System.out.println("queueList vorher = "+..); // queueList ausgeben, counter usw.
try {
  queueList.enter(8);
} (catch Exception e) {
  System.out.println("exception, e = "+..);
  System.out.println("exception, queueList ist dabei = "+..); // queueList ausgeben, counter usw.
}
System.out.println("queueList nachher = "+..); // queueList ausgeben, counter usw.

usw., mit derartigen Ausgaben lässt sich jedes einfache Problem vollständig klären

das ganze selbstverständlich in einem einfachen main-Programm,
Zusätze wie
> @Test(expected = OverflowException.class)
könnten wieder alle möglichen unbekannten Probleme einbringen,
Rücksetzung auf Ursprungszustand kann ohne Weiteres Bestandteil irgendeines Test-Frameworks sein,
wie bei Debuggern immer vom Worst Case ausgehen