- baseportal Dokumentation

Titel:

Standardmässig gibt baseportal Fehler direkt an der Stelle der HTML-Seite aus, an der der Fehler passiert ist. Die Fehlermeldungen können genauso wie alle anderen Ausgabetexte mit <c>set_language</c> auf eine andere Sprache umgestellt oder beliebig umdefiniert werden (s. Anhang).

<h2>Befehle geben <c>undef</c> bei Fehler zurück</h2>

Tritt bei der Ausführung eines baseportal-Befehls ein Fehler auf, so bricht dieser üblicherweise ab und gibt den Wert <c>undef</c> zurück. Ein Test ob ein Befehl erfolgreich war sieht demnach so aus:

<code>
if(put ["Name", "Stefan"], "kunden")
{
	# Befehl wurde erfolgreich ausgeführt
} else
{
	# Während des Befehls ist ein Fehler aufgetreten
}
</code>

Schreibt einen neuen Eintrag in die Datenbank <c>kunden</c> - tritt dabei ein Fehler auf, wird darauf entsprechend reagiert.

Üblich ist auch folgende Schreibweise:

<code>
put ["Name", "Stefan"], "kunden" or out "FEHLER!";
</code>

Gibt <c>FEHLER!</c> aus, wenn ein Fehler aufgetreten ist.

Um die baseportal-eigene Fehlerausgabe zu unterbinden, muss man die Variable <c>$_error_mode</c> auf <c>no</c> setzen.

<h2>Variablen</h2>

<tab>
Variable	Beschreibung
\$_error	Fehlername des letzten Fehlers (s. Anhang)
%_error	enthält (sofern vorhanden!) alle verfügbaren Informationen über den letzten Fehler:<br><c>name</c> => nochmals den Fehlernamen des letzten Fehlers<br><c>text</c> => Ausführliche Fehlerbeschreibung des letzten Fehlers in der ausgewählten Sprache<br><c>line</c> => Zeilennummer des Scripts, bei der der Fehler aufgetreten ist<br><c>htx</c> => Name des Templates, in dem der Fehler aufgetreten ist<br><c>from</c> => Funktion in der der Fehler aufgetreten ist
\$_error_mode	<i>ungesetzt/leer</i> = Fehler an der Stelle des Auftretens ausgeben<br><c>top</c> = gesammelt zu Beginn<br><c>bottom</c> = gesammelt am Ende<br><c>no</c> = keine Fehler ausgeben
@_error	Array von <c>%_error</c>-Hashes: Alle gesammelten (noch nicht ausgegebenen) Fehler<br>also <c>$_error[0]{name}</c> wäre der Name des ersten noch nicht ausgegebenen Fehlers
\$_error_handler	Übergebene Routine wird im Fehlerfall ausgeführt
</tab>

<h2>Selbst Fehler erzeugen</h2>

Durch den Aufruf der Routine <c>error</c> kann von Hand ein beliebiger Fehler erzeugt werden:

<code>
error "Es ist ein unglaublich schlimmer Fehler aufgetreten!";
</code>

<c>error</c> gibt selbst <c>undef</c> zurück. Um den fehlerhaften Abbruch einer Unterroutine anzuzeigen bietet sich folgende Schreibweise an:

<code>
sub my_sub
{
	my($val)=@_;

return error "Der erste Parameter darf nicht leer sein!" if $val eq "";

...code...

1;
}
</code>

Gibt die Fehlermeldung <i>Der erste Parameter darf nicht leer sein!</i> aus und kehrt mit einem <c>undef</c> zurück, wenn der übergebene Parameter leer war. Ist alles fehlerfrei gelaufen, gibt die Routine <c>1</c> - logisch <c>wahr</c> zurück. <c>my_sub</c> verhält sich damit wie alle baseportal-Befehle.

<h2>Eigene Fehlerroutine einsetzen</h2>

Durch die Definition einer eigenen Fehler-Routine kann selbst auf Fehler reagiert werden. Ein Verweis auf die Routine muss an <c>$_error_handler</c> übergeben werden. Diese wird dann aufgerufen, wenn ein Fehler auftritt. Als erster Parameter wird der Fehlername übergeben, gefolgt von weiteren Angaben. Beim Fehler <c>perl_error</c> ist dies zum Beispiel der Text des Perl-Fehlers.

Ist der Rückgabewert logisch <c>falsch</c> (also 0 oder leer oder <c>undef</c>), so wird danach die baseportal-eigene Fehlerroutine ausgeführt, bei logisch <c>wahr</c> (jeder andere Wert, z.B. 1) nicht.

<code>
$_error_handler=sub
{
	put $_error_text, "error_log.htx";
	0;
}
</code>

Protokolliert alle aufgetretenen Fehler in der Datei <c>error_log</c> mit. Aufgrund des Rückgabewerts <c>0</c> wird danach die baseportal-Fehlerroutine aufgerufen und der Fehlertext also wie normal ausgegeben. Der Nutzer merkt keinen Unterschied.

Name: Passwort: Stichworte: Version: 1 2 3 Angebot:

Ohne Änderungen zurück zur Seite

Neue Seite erstellen