Na ostatnim DevCrowd Sebastian Pietrowski poruszył kwestię związaną z być i nie być instrukcji GOTO.

Jak wiadomo w Javie zarezerwowano słowo goto, ale nie jest ono zaimplementowane. Kwestią sporną pozostaje czy ta instrukcja jest sensowna w języku obiektowym czy też nie. W zamian za nią pedrowaty wskazał, że nadal można używać instrukcji break i continue. Co więcej powiem wam, że można tych instrukcji używać w taki sam sposób jak używano słowa kluczowego goto.

Listing 1. użycie break jak goto

public class SimpleGoTo {
	public static void main(String[] args) {
		int i = 0;
		int j = 0;

		REPEAT: {
			while (i < 10) {
				i++;
				System.out.println(i + "/" + j);
				if (j > 5) {
					break REPEAT;
				}
				j++;
			}
			System.out.println(i + "///" + j);
		}
	}
}

Jak się pobawicie to dojdziecie do wniosku, że można używać namiastki goto w postaci break LABEL. To był przykład z pętlą teraz trochę bardziej mieszający w głowie, czyli break LABEL z ifem:

Listing 2. użycie break z if

public class SimpleGoTo {
	public static void main(String[] args) {
		int i = 0;
		int j = 0;
		REPEAT: {
			MAGIC: {
				while (i < 10) {
					i++;
					System.out.println(i + "/" + j);
					if (j > 5) {
						break MAGIC;
					}
					j++;
				}
			}
			if (i + j > 10){
				break REPEAT;
			}
			System.out.println(i + "///" + j);
		}
	}
}

Zatem można stwierdzić, że dopóki pozostajemy w danym zakresie (bloku kodu ograniczonym { i }) to możemy używać namiastki goto. Do czego można tego użyć?

W swojej karierze spotkałem się tylko raz z użyciem takiej konstrukcji. Mianowicie w ten sposób można kontrolować przepływ sterowania w programie jeżeli migrujemy z kodu pre-strukturalnego. Dzięki temu można w miarę łatwo przenieść zasadę działania oryginalnego programu, a dopiero później zastosować refaktoryzacje mające na celu zmianę struktury kodu.

Tergo typu konstrukcji nie stosujemy w nowo utworzonym kodzie. Dlaczego? Ponieważ jak ostatni raz tego użyli to meteoryt walnął w Ziemię i powstała nauka zwana Paleontologią. A na serio… trudność utrzymania takiego kodu jest bardzo duża. Wprowadzanie zmian ciężkie, a awaryjność wysoka. Poza tym taki kod nie ma sensu w przypadku programowania obiektowego.

idę spać.