Re: Fehlerbehandlung

Thomas 'PointedEars' Lahn wrote:

> Andreas Born wrote:
>> Ich würde gerne Scriptfehler auffangen und die information an den
>> Webserver weiterleiten.

> Grundsätzlich halte ich Deinen Ansatz für verkehrt. Fehler im
> clientseitigen Script-Code sollten sich beim Test und nachher
> bei der Verwendung, mithin beim Client, manifestieren -- oder
> eben durch sinnvolle Programmierung gar nicht erst auftreten.

Das wird natürlich angestrebt. :)
Allerdings handelt es sich nicht um in statische HTML-Seiten
eingebetteten Scriptcode, sondern um ein Addon, welches z.B. mittels
Firefox-Plugin in verschiedene Internetseiten nachträglich eingefügt
wird.

Da sich der Aufbau dieser Seiten natürlich ändern kann, will ich mir
entsprechende Fehler melden lassen, um daraufhin schnellstmöglich
reagieren zu können.


>> Das Weiterleiten funktioniert bereits,

> Das mag ich bedreifeln. Es funktioniert vielleicht in bestimmten
> Fällen.

Was meinst Du genau?
Ich habe eine Fehlerroutine, die im hoffentlich selten auftretenden
Fehlerfall aufgerufen wird, und dynamisch ein dummy-image vom server
nachlädt und hierbei die Daten url-kodiert überträgt. Serverseitig fängt
ein php-skript die Anfrage ab und liefert das image zurück.

>> ich bin aber unsicher ob es vernünftiger ist, mit try..catch zu
>> arbeiten, oder mit window.onerror.
>>
>> Letzteres liefert mir zusätzlich zum Fehlertext die Zeilennummer,

> Interessant, danach suche ich gerade. Kannst Du dafür mal ein
> Beispiel geben?

nicht wirklich, da das nur beim ie funktioniert.
Der dritte Parameter der errorHandler-Funktion enthält dort die
Zeilennummer.

window.onerror = function(err, url, line) {
alert(err + ' in line ' + line);
}

> Ersteres liefert Dir dies per line-Eigenschaft des Error-Objekts auch.

Ahja, das ist mir neu.
Klappt aber nicht im IE. Das hat hier nur die Eigenschaften
{name, message, number, description}.

Beim Firefox habe ich
{name, message, fileName, lineNumber, stack}.

Daher hatte ich gehofft, irgendwie beide Methoden kombinieren zu können.


Hier mal mein Grobaufbau:

function errorHandler(err, url, line, except) {
var isExcept = false;
var exData = '';
if (except) {
isExcept = true;
err = except.message;
if (except.lineNumber) { line = except.lineNumber;}
}
alert(err + ' in line ' + line);
var url = 'http://example.org/rq/screrr.js?err=' +
encodeURIComponent(err) /* + .... */ ;
// new image mit .src=url laden
return true;
}

function objMyScript() {
/* local vars, member vars, constructor instructions */

function main() {
alert('started');
document.getElementById('not here').style.display = 'none';
}

/* Prototyping additions, e.g.: */
if (typeof HTMLElement != 'undefined' &&
!HTMLElement.prototype.getElementById) {
HTMLElement.prototype.getElementById = function(id) {
/* ... */
}
}
}

if (typeof(myScript) == 'undefined') {
var myScript = new objMyScript();
}

var oldErrorHandler = window.onerror;
window.onerror = errorHandler;

try {
myScript.main();
} catch(except) {
errorHandler(null, null, null, except);
}

window.onerror = oldErrorHandler;


>> Es ist jedoch ganz wichtig, daß andere Skriptbereiche weiterhin
>> abgearbeitet werden, weshalb ich dann doch try..catch bevorzugen
>> würde.

> Das ist ein Widerspruch. Wird Exception-Behandlung nicht unterstützt,
> wird gar kein Scriptbereich abgearbeitet, weil bereits die
> Compilierung mit einem SyntaxError fehlschlägt. Zudem ist der
> onerror-Handler genau dafür da, dass die fehlerhafte oder nicht
> unterstützte Anweisung eben nicht zu einem Script-Abbruch führt.

Hmm. Verstehe.

Nunja, der innerhalb meines try..catch-blocks abgearbeitete
scriptbereich soll sofort verlassen werden, daher wäre try..catch
vermutlich sinnvoller als onerror.

Bei mir wird jedoch nach dem errorhandler kein weiterer Code mehr
abgearbeitet:

window.onerror = function(err) {
alert('Fehler: ' + err);
return true;
}
causeError();
alert('Fehler wurde abgefangen');

Die letzte alert-Anweisung wird bei mir nie ausgeführt.
Irgendetwas ist mir dahingehend doch noch unklar.
Wenn ich causeError(); in einen try..catch-block stecke, dann geht's
natürlich, im Beispiel scheint die Kompilierung bei causeError(); jedoch
abzubrechen.

> Das Folgende funktioniert nachweislich mit und ohne Exception-Support.
> Ob es auch vernünftig ist, hängt davon ab, wie es eingesetzt wird.
>
> window.onerror = function()
> {
> this.onerror = null;
> return true;
> };
>
> eval('try { ... } catch (e) { ... }');
>
> // ab hier führen alle Fehler wieder zum Abbruch (des Kontexts)
> window.onerror();

Danke, sieht sehr interessant aus!
Damit könnte ich eine weiche für try und onerror schreiben...


>> Kennt jemand evtl. eine Internetseite, wo man entsprechende
>> Überlegungen/Hinweise dahingehend findet?
>
> Da es keine "Internetseiten" gibt: nein.

auch wieder wahr :)

Viele Grüße,
Andreas

.