Fehlerbehandlung | ab Version 3 |
Tritt bei der Ausführung eines baseportal-Befehls ein Fehler auf, so bricht dieser üblicherweise ab und gibt den Wert undef zurück. Ein Test ob ein Befehl erfolgreich war sieht demnach so aus:
if(put ["Name", "Stefan"], "kunden") { # Befehl wurde erfolgreich ausgeführt } else { # Während des Befehls ist ein Fehler aufgetreten }
Schreibt einen neuen Eintrag in die Datenbank kunden - tritt dabei ein Fehler auf, wird darauf entsprechend reagiert.
Üblich ist auch folgende Schreibweise:
put ["Name", "Stefan"], "kunden" or out "FEHLER!";
Gibt FEHLER! aus, wenn ein Fehler aufgetreten ist.
Um die baseportal-eigene Fehlerausgabe zu unterbinden, muss man die Variable $_error_mode auf no setzen.
Variable | Beschreibung |
---|---|
$_error | Fehlername des letzten Fehlers (s. Anhang) |
%_error | enthält (sofern vorhanden!) alle verfügbaren Informationen über den letzten Fehler: name => nochmals den Fehlernamen des letzten Fehlers text => Ausführliche Fehlerbeschreibung des letzten Fehlers in der ausgewählten Sprache line => Zeilennummer des Scripts, bei der der Fehler aufgetreten ist htx => Name des Templates, in dem der Fehler aufgetreten ist from => Funktion in der der Fehler aufgetreten ist |
$_error_mode | ungesetzt/leer = Fehler an der Stelle des Auftretens ausgeben top = gesammelt zu Beginn bottom = gesammelt am Ende no = keine Fehler ausgeben |
@_error | Array von %_error-Hashes: Alle gesammelten (noch nicht ausgegebenen) Fehler also $_error[0]{name} wäre der Name des ersten noch nicht ausgegebenen Fehlers |
$_error_handler | Übergebene Routine wird im Fehlerfall ausgeführt |
Durch den Aufruf der Routine error kann von Hand ein beliebiger Fehler erzeugt werden:
error "Es ist ein unglaublich schlimmer Fehler aufgetreten!";
error gibt selbst undef zurück. Um den fehlerhaften Abbruch einer Unterroutine anzuzeigen bietet sich folgende Schreibweise an:
sub my_sub { my($val)=@_; return error "Der erste Parameter darf nicht leer sein!" if $val eq ""; ...code... 1; }
Gibt die Fehlermeldung Der erste Parameter darf nicht leer sein! aus und kehrt mit einem undef zurück, wenn der übergebene Parameter leer war. Ist alles fehlerfrei gelaufen, gibt die Routine 1 - logisch wahr zurück. my_sub verhält sich damit wie alle baseportal-Befehle.
Durch die Definition einer eigenen Fehler-Routine kann selbst auf Fehler reagiert werden. Ein Verweis auf die Routine muss an $_error_handler übergeben werden. Diese wird dann aufgerufen, wenn ein Fehler auftritt. Als erster Parameter wird der Fehlername übergeben, gefolgt von weiteren Angaben. Beim Fehler perl_error ist dies zum Beispiel der Text des Perl-Fehlers.
Ist der Rückgabewert logisch falsch (also 0 oder leer oder undef), so wird danach die baseportal-eigene Fehlerroutine ausgeführt, bei logisch wahr (jeder andere Wert, z.B. 1) nicht.
$_error_handler=sub { put $_error_text, "error_log.htx"; 0; };
Protokolliert alle aufgetretenen Fehler in der Datei error_log mit. Aufgrund des Rückgabewerts 0 wird danach die baseportal-Fehlerroutine aufgerufen und der Fehlertext also wie normal ausgegeben. Der Nutzer merkt keinen Unterschied.
Beachten Sie den abschliessenden ; da dies eine Variablenzuweisung und kein Block wie bei der Definition einer Routine ist.
Fehler die innerhalb der eigenen Fehler-Routine auftreten, können nicht mehr abgefangen werden.
Durch eigene Fehlerroutinen kann man alle in einer Seite auftretenden Fehler abfangen und beliebig ändern. Dies kann natürlich nicht gelingen, wenn die gewünschte Seite garnicht erst gefunden wird. Für diesen Fall gibt es die Möglichkeit eine spezielle Seite namens _error_no_page im Hauptverzeichnis anzulegen, die dann stattdessen ausgegeben wird.