Schlagwort-Archive: (p)fund(s)stück

(P)Fund(s)stück der Woche (KW41)

In meiner Aufgabe als QA hab ich heute mal ein nettes Stück strukturierten Code sichten dürfen.
Es ja schon verwunderlich dass riesen Portale noch gänzlich ohne Objekte auskommen, aber wer sowas verbricht (Siehe Skeleton unten), dem gehören aber beide Ohren lang gezogen. Das unten aufgeführte Skeleton gehört in eine index.php, in welcher je nach Bedingung weitere dieser strukturierten Glanzstücke inkludiert werden, die mit nicht weniger bedingungsloser Effizienz durch Bedingungen glänzen. Ihr merkt wahrscheinlich, worauf ich hinaus will, aber seht selbst:
(P)Fund(s)stück der Woche (KW41) weiterlesen

(P)Fund(s)stück der Woche

Eine Debugger-Object, daß scheinbar suizidgefährdet ist.


class Debugger{

[...]
	function runError($content,$typ){		
		
		 switch($typ){
		 	case E_USER_ERROR:
		 	 	unset($this);
		 		trigger_error($content, E_USER_ERROR);
		 		die();
		 		break;
		 	case E_USER_NOTICE:
		 		trigger_error($content, E_USER_NOTICE);
		 		break;
		 	case E_USER_WARNING:
		 		trigger_error($content, E_USER_WARNING);
		 		break;
		 	default:
		 		unset($this);
		 		trigger_error($content, E_USER_ERROR);
		 		die();
		 }
	}

}

Man nehme mal daß wir der Methode runError einen E_USER_ERROR (256) übergeben, schaun wir doch mal, was da passieren würde.

$deb = new $Debugger() ;
$deb->runError(‚die hard!‘,E_USER_ERROR);

Der switch findet ordnungsgemäß raus, das wir zum case-Block:E_USER_ERROR müssen und tötet sich erstmal selber … versucht es zumindest, denn im Falle eines Erfolges würde ja sonst das darauffolgende „trigger_error()“ nicht mehr ausgeführt werden.
Wird sie aber, da nur kurzzeitig das Object sich selber verliert dann sich aber seiner Existens wieder besinnt und wie befohlen einen Fehler wirft. In diesem Falle einen E_USER_ERROR was im Falle dieses Scriptes auch den Effekt des sofortigen Todes zur Folge hat.

Aber …
…sollte auch nur kleines Fünkchen Leben noch in dem Script selber stecken, wird mit dem anschließenden „die()“ auch garantiert, daß die komplette (jetzt schon tote) Ausführung auch wirklich beendet wird. Nachdem nun das Script zweimal gestorben ist, das erste zählen wir mal als mißglückten Suizidversuch, darf das Script dann wiederum ordnunggemäß aus dem switch springen und somit die Methode beenden.

Fein, alles tot (garantiert!!!) und fertig …

Ergo: Wenn du suizidgefährdete Klassen baust, sorge lieber „mehrfach“ dafür, daß sie nicht heile aus der Sache rauskommen!

so far – tucci