Re: Fehlerbehandlung

Thomas 'PointedEars' Lahn wrote:

> Andreas Born wrote:
>> 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 verstehe ich nicht. Kannst Du konkreter werden?

Wenn der Seitenbetreiber den Aufbau seiner HTML-Dokumente ändert (z.B.
IDs umbenennt), würde das Script nicht mehr funktionieren, weil es die
entsprechenden Tags nicht mehr findet. Tritt dieser Fall bei einem
Benutzer des Plugins ein, dann speichere ich die Fehlermeldung in einem
Errorlog auf dem Server. Und werde so darüber informiert.

Das eigentliche script wird durch das Plugin vom Server geladen (d.h.
mittels createElement wird ein Script-Element mit entsprechendem
src-Attribut in das Dokument eingefügt). Ich brauche also nur das Script
(auf dem Server) ändern und die Plugin-Benutzer profitieren davon.

Nur muß ich eben von der Notwendigkeit einer Änderung erfahren.

>> if (typeof HTMLElement != 'undefined' &&
>> !HTMLElement.prototype.getElementById) {

> Hier gehst Du ohne Not davon aus, dass, wenn HTMLElement
> existiert, auch HTMLElement.prototype existieren muss.

stimmt. Weil ich mom. nur IE und Firefox unterstütze, bin ich
etwas leichtsinnig geworden ;-)

> <URL:http://pointedears.de/scripts/test/whatami>

Ist klar.

>> HTMLElement.prototype.getElementById = function(id) {
>> /* ... */
>> }

> Das ist IMHO Unfug. Das einzige DOM, welches derzeit DOM-Interfaces
> als gleichnamige Konstruktoren bereitstellt, ist das Gecko-DOM, und da
> wird Document::getElementById() bereits unterstützt. Sollten also
> zukünftige Browserversionen, die derzeit noch nicht ersteres Feature
> bieten, es in Zukunft bieten, so werden sie Document::getElementById()
> unterstützen müssen, um konkurrenzfähig zu bleiben (derzeit IE 5.0+,
> Opera 6.0+).

ok, ich gebe ja zu, daß ich mich primär auf das IE-DOM konzentriert
habe, weil hier die meisten der von mir benötigten Funktionen bereits
existieren. Und bei Gecko-basierten Browsern kann man eben schön die
"fehlenden" Funktionen ergänzen. Für Opera und Mozilla suche ich eh noch
eine Lösung für die eigentliche Plugin-Einbindung, daher ist momentan
nur IE und Firefox aktuell. Leider.

Browser-weichen sind für mich ein Horror, die wollte ich eben unbedingt
vermeiden, deswegen erschien mir diese Variante vorerst am sinnvollsten.

getElementById kann ich dann ja rauswerfen.
Daneben habe ich u.a., insertAdjacentHTML, id, className,
innerText. Ich nehme an, daß diese im Gegensatz zu getElementById nicht
überall definiert sind?


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

> Das ist auch nicht sehr sinnvoll. Vergleiche:
>
> var myScript;
> alert(typeof myScript); // undefined

Nützt mir nichts.
In meinem Fall gibt es nur zwei Situationen:
1. Das Objekt wurde bereits von mir erstellt
2. Das Objekt wurde noch nicht von mir erstellt.

Der 3. Fall, daß das objekt existiert, aber _nicht_ von mir
erstellt wurde, kann im Grunde ausgeschlossen werden.


>> var oldErrorHandler = window.onerror;
>> window.onerror = errorHandler;
>>
>> try {
>> myScript.main();

> Das funktioniert höchstens zufällig. Nicht `myScript' oder sein
> Prototyp hat nämlich die Eigenschaft `main', sondern der Konstruktor
> selbst. Und das auch nur in JavaScript, als Erweiterung zu
> ECMAScript.

Sorry, Asche auf mein Haupt; main() war nur ein Namensbeispiel, ich
hatte nicht daran gedacht, daß es das tatsächlich gibt. :-/

So passt es wohl eher..?

function objMyScript() {
function start() {
alert('started');
}
this.start = start;
}

Oder ist das performanter...?

function objMyScript() {
this.start = function() {
alert('started');
}
}


> Wenn Du das jetzt noch änderst in
>
> objMyScript.prototype.main = function()
> {
> function isMethodType(s)
> {
> return (s == "function" || s == "object");
> }
> alert('started');
> var t, o;
> if (isMethodType(typeof document.getElementById)
> && (o = document.getElementById('not here'))
> && typeof o.style != "undefined"
> && typeof o.style.display != "undefined")
> {
> o.style.display = 'none';
> }
> }
>
> löst sich die Notwendigkeit, hier Fehler-/Exception-Behandlung
> zu betreiben, vermutlich in ein Logikwölkchen auf.

Ok. Würde mich aber einiges an Performance kosten, jedes einzelne Objekt
vorher zu überprüfen. Da im Fehlerfalle der akuelle Scriptbereich eh
nicht weiter abgearbeitet werden soll, erscheint es mir sinnvoller,
einfach einen Fehler zu werfen. Ist zwar unsauber in der programmierung,
erscheint mir jedoch effektiver.

>> } catch(except) {
>> errorHandler(null, null, null, except);
>> }
>>
>> window.onerror = oldErrorHandler;
>
> Das ist so aber Unfug. Ich schrieb das eval() oben nicht umsonst.
> Nur damit (auszuwertender Code im String-Literal) lässt sich nämlich
> vermeiden, dass es zu einem Kompilierungs-Fehler kommt, wenn
> Exception-Handling nicht unterstützt wird.

Das hatte ich schon verstanden. :-)
Der Code stellt nur die bisherige Situation nach.

>> 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.

> Definiere: "bei mir"

IE 6.0.2800
FireFox 0.9.3 / Gecko 2004/0803
Mozilla 1.5 / Gecko 2003/1007
etc...

Aber eigentlich ist es klar, die kompilierung bricht ab, weil
causeError() nicht definiert ist. Innerhalb eines try..catch blocks
passiert das nicht.


>> 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.
>
> Was tut causeError()? Ist so eine Methode überhaupt definiert?

Eben nicht, die soll ja testweise einen fatalen Fehler auslösen.

Aber genau das bedeutet, daß ich mich nicht auf onerror verlassen kann.
Liefert mir getElementById ein "Tag-Objekt" zurück, welchen z.B. keine
firstChild-Eigenschaft besitzt (z.B. textnode), würde mir onerror in
dieser Situation zwar eine Fehlermeldung liefern, aber das gesamte
script (also nicht nur der aktuelle scope) würde abgebrochen werden (und
ich habe scriptbereiche, die trotzdem ausgeführt werden sollen).

Und die Überprüfung jedes einzelnen Objektes frisst wie schon erwähnt
zuviel Performance.


Viele Grüße,
Andreas

.

Relevant Pages

  • Fehler bei der Ausführung eines Scripts
    ... Hier einmal das Script ... Function Ping_Host ... Hier soll laut der VBS Datei ein Fehler in folgender ...
    (microsoft.public.de.german.scripting.wsh)
  • Re: Existenzprfung per try catch im Opera
    ... Das funktioniert hier eben nicht (Fehler: ... deswegen der Versuch per try/catch. ... function registerForm{ ...
    (de.comp.lang.javascript)
  • Re: Fehlerbehandlung
    ... > Das eigentliche script wird durch das Plugin vom Server geladen (d.h. ... denn `myScript' existiert ja; ... Was auf unsaubere Programmierung hindeutet. ... > function objMyScript() { ...
    (de.comp.lang.javascript)
  • Highlighting eines ListenElements: Verkomplizierung...
    ... mit dem Scriptangebot von Martin zufrieden (es brachte gleich das ... was ich durch das Script von Martin ... function expandcontent{ ... font-family: Tahoma; ...
    (de.comp.lang.javascript)
  • Re: Funktionsname als Argument
    ... FUNCTION test: boolean; ... kein Array ist. ... Ansonsten hätte man das strenge Pascal mit relaxten C-Idiomen ... Einzig in den Modi macpas und tp wirft das einen Fehler. ...
    (de.comp.lang.pascal)