Re: Fehlerbehandlung

Thomas 'PointedEars' Lahn wrote:

> Der Vorteil ist beispielsweise, dass Du reale Fehler von
> Markup-basierten "Fehlern" unterscheiden kannst.

Ok, das ist ein gutes Argument.

>> Zu den Nachteilen zählt jedenfalls die schlechtere Performance.
> Die ist vernachlässigbar klein.

Werd ich einfach mal testen.

>> Dazu müsste ich ich den FehlerStatus in einer Variable speichern und
>> vor jedem Funktionsaufruf prüfen, denn im Fehlerfalle soll das script
>> ja nichts mehr tun.

> Es genügt, die verwendeten Methoden und ihr Ergebnis zu testen. Wird
> die Methode für ein Objekt mehrfach verwendet, reicht es, die Existenz
> einmal zu testen.

Soweit klar. Testen kann ich jedoch erst dann, wenn das objekt
existiert; könnte ich denn davon ausgehen, daß bestimmte
elementabhängige Methoden wie z.B. .xyz immer für den Elementtyp
existieren, wenn einmal ein test positiv war? Dann könnte ich am Anfang
des skriptes häufig verwendete element.methoden-Kombinationen testen:

function isMethod(s) { return (s == "function" || s == "object"); }

var m_div_xyz_exists = isMethod(document.createElement('div').xyz);
var m_a_appendChild_exists =
isMethod(document.createElement('a').appendChild);
....

Würde das für Funktionen Sinn machen?
Was passiert z.B. bei Eigenschaften wie className, wenn das Attribut im
Element nicht gesetzt ist?

>> Ok, ich könnte bei jeder Überprüfung im Fehlerfall gleich eine
>> entsprechende Info über den Fehlerort/Grund loggen, aber m.E.
>> überwiegen dennoch die Nachteile. Try..Catch löst das Problem
>> mit ein paar wenigen Zeilen.

> Und liefert im Wesentlichen den Fehler "Es ist ein Fehler
> aufgetreten". Toll.

ack. Deshalb ja Eingangs die Frage bzgl try..catch und onerror().
Aber ich ich denke Du hast mich jetzt doch überzeugt.

>>>> (d.h. mittels createElement wird ein Script-Element mit
entsprechendem
>>>> src-Attribut in das Dokument eingefügt).

>> Bisher hat es bei allen Tests funktioniert.

> Mit welchen Browsern hast Du getestet? Mit welchen Versionen/Service
> Packs? Mit welchen Betriebssystemen? Auf welchen Plattformen?

Wäre es denn sicherer, das script direkt einzufügen, also nicht via
src-attribut laden zu lassen?

Wie auch immer, das ist für mich mom. die einzige
Möglichkeit das zu realisieren.

>> Daß es bei manchen Browsern (wie Opera?) nicht funktioniert, braucht
>> mich ja nicht interessieren, weil bei denen das Plugin eh nicht
>> läuft. Sogesehen erhält jeder unterstützte Browser eine
>> "Maßanfertigung". Wenn ich für alle Fälle das selbe Script verwenden
>> kann, wäre das natürlich von Vorteil.

> Es ist nicht nötig und daher Unfug, jedem Browser eine Maßanfertigung
> zu liefern. Tatsächlich sollte jedes verbreitete DOM bedient werden,
> sofern es zutreffen kann. Das sind hier derzeit W3C DOM Level 2 und
> IE4-DOM.

Das bezog sich auf das "Plugin", nicht auf das Script.
Das script soll natürlich für alle unterstützten Browser funktionieren.
Firefox benutzt natürlich ein anderes Interface für die Erweiterungen
als der IE. Und wenn ich später Opera unterstützen sollte, brauche ich
eine dritte Lösung, bei der das Script evtl. gar nicht eingesetzt
werden kann.


> Zudem: Wenn es bei einem Browser nicht funktioniern sollte, so ist
> das DOM "defekt".

> Nein. Denn _nirgendwo_ ist dokumentiert, wie und ob nachträglich
> eingefügte script-Elemente _verarbeitet_ werden sollen. D.h. es
> ist nicht dokumentiert, dass die Script-Engine mit dem Parsen
> des Inhalts dieses Elements betraut wird.

Verstehe. Trotzdem halte ich das für sinnfrei. Wenn man ein Element über
das DOM einfügt geschieht das natürlich, um das Dokument zu verändern.
Wäre doch idiotisch wenn man ein a-Element einfügt, das dann zwar im
Dokument vorhanden ist, aber nicht auf klicks reagiert, weil es zwar
eingefügt, aber nicht 'verarbeitet' wird...

Wäre doch wünschenswert, daß entsprechendes standardisiert wird.

Ich vermisse bei script-Element sowieso ein tag, mit dem kontrolliert
wird, wann mit der Abarbeitung des skriptes begonnen wird. Teilweise
kann man das ja kontrollieren, aber das nun wirklich nicht zuverlässig.

>> Beides trifft nicht zu, stattdessen liegt Fall 3 vor:
>> Benutzer != Seitenbetreiber != ich

> Was soll dann die Fehlerberichtsfunktion basierend auf fehlenden
> Elementen im Markup? Weder der Benutzer noch Du wirst den Anbieter
> veranlassen können, sein Markup zu ändern, da er ja nicht wirklich
> betroffen ist.

Eben. Deswegen muß ich sobald ich Kenntnis von einer solchen Änderung
habe, mein Script ändern. Da das vom Server geladen wird, profitieren
alle Benutzer von der Änderung.

>> Interessant.
>> Gibt es denn eine vernünftige Javascript-referenz?

> Das ist keine Ja-oder-Nein-Frage und auch keine, die sich in einem
> Satz beantworten lässt (wer das dennoch tut, hat schlicht keine
> Ahnung). Zunächst mal muss man Folgendes verstehen:
[...]
[...]
[...]

Höchst interessant. Vielen Dank für die Informationen, da habe ich
einiges zu lesen und zu lernen.

>> Oder anders gefragt:
>> Wenn mein Plugin z.B. ab Firefox 0.9.3 laufen soll, warum könnte man
>> nicht einfach prüfen, ob es sich tatsächlich um das Gecko-DOM
>> handelt,
>> um dann ggf. abhängig von DOM-Version evtl. fehlende aber benutzte
>> Routinen nachzubilden..?
>
> Dazu müsstest Du auf proprietäre DOM-Features prüfen, die aufgrund
> ihrer Natur nicht zuverlässig sind. Schon in der nächsten Version
> könnte das Feature nicht oder anders implementiert sein und es wird
> das fhcsale DOM erkannt. Bei standardisierten Features kann man sich
> solche Änderungen nicht so einfach erlauben, weil das Inkompatibilität
> zu Browsern bedeuten würde, die den Standard weiterhin oder dann wie
> spezifiziert implementieren.

Verstehe.

Wenn ich das ganze mal aus einer anderen Sichtweise betrachten darf, man
könnte doch eigentlich sowohl ein Gecko-DOM als auch eine
ECMAScript-Imlementation o.ä. als (nun echtes) Plugin entwerfen, oder
nicht? Dann würde jeglicher JS-Code nicht über ein script-element,
sondern über ein object-element mit entsprechenden Attributen/paramteren
referenziert werden. Und man hätte als JS-Coder kein Problem, das
Gecko-DOM auch im IE zu nutzen. Würde natürlich nur Sinn machen, wenn
sich dieses Plugin entsprechend weit verbreiten würde. Was hieltest Du
davon?

Das wäre zwar für normale Websites weniger zu gebrauchen, aber eben
gerade für Plugins/addons/etc...
Du hast ja in Deiner Script-Sammlung auch eine DOM-Nachbildung, wenn ich
das richtig sehe?

> Übrigens gibt es eine standardkonforme Möglichkeit, das unterstützte
> DOM-Level abzufragen:
[...]
[...]

Ok, das hatte ich gemeint. Sehe aber auch, daß es nicht wirklich
viel bringt. Schade.


>> Man kann natürlich eigene Funktionen schreiben, z.B.
>> getInnerText(node).
>> Allerdinsg glaube ich, daß die bereits im DOM implementierten
>> Funktionen schneller abgearbeitet werden, weshalb ich beim

> Da es offenbar ausser in IE nur in Firefox laufen soll: Inwiefern
> ist .textContent langsamer oder unbequemer als .innerText?

Gar nicht. Das in JS nachzubilden ist (verm.) langsamer. Und der
zusätzliche Funktionsaufruf, der ohne prototyping für beide Browser
notwendig ist. Aber darauf kommts nun wirklich nciht an.

> Bei insertAdjacentHTML() kann ich verstehen, dass es eleganter
> wirkt als .appendChild(document.createElement(...)) bzw.
> .appendChild(document.createTextNode(...)). Ob es auch
> schneller ist, ist eine andere Frage, denn sowohl die vorhandene
> Implementation in IE als auch eine Emulation in z.B. Mozilla/5.0
> erfordert zusätzlich Markup-Parsing; die Emulation wäre dann nicht
> nur langsamer als das Original, sondern auch langsamer als die
> verfügbare standardkonforme Alternative -- letzteres dürfte auch
> für `innerHTML' gelten.

Hm. Müsste man mal testen. Da teilweise ganze "HTML-Blöcke" eingefügt
werden, kann ich mir vorstellen, daß das html-parsen schneller ist, als
zig-mal entsprechende DOM-Methoden aufzurufen. Wenn ich z.B nur ein
einzelnen Element einfüge, benutze ich i.d.R. auch .createElement...

> Übrigens: Elemente haben Attribute und bestehen aus Tags (Start- und
> End-Tag, können jeweils optional sein) sowie Inhalt (kann leer, d.h.
> nicht vorhanden, sein).

Ist klar, hab die Begriffe vebuchselt.

>>>> Der 3. Fall, daß das objekt existiert, aber _nicht_ von mir
>>>> erstellt wurde, kann im Grunde ausgeschlossen werden.
>>> Also bei sauberer Programmierung schlicht
>>> var myScript = new objMyScript();
>> Bei "HTML-seitigem" JS wäre das klar, aber die Sache liegt
komplexer.

> Das verstehe ich nicht.

Der IE ermöglicht das Ausführen von Scripts, ohne daß diese im Markup
eingebunden sind. (Durch das im IE-Prozess geladene "Plugin"). Wenn ich
auf diese Weise zwei scripte ausführe, kann folgendes passieren:

// script 1
var myVar = 'defined';

// script 2
alert('JS ist ' + ((myVar == 'defined')?'aktiviert':'deaktiviert'));


// plugin
'schematisch:
IE...ExecuteScript(script1)
IE...ExecuteScript(script2)


>> 3. Ladezeiten/traffic
>>
>> Das durch das erste Skript geladene zweite Skript soll so klein
>> wie möglich sein,

> Wenn es denn geladen wird. Aus welchem Grund das zweite Script nicht
> ins erste integriert werden kann (und damit immer funktioniert),
> verstehe ich auch nicht.

Das erste skript analysiert die seite und sammelt Informationen.
Diese Infos werden durch die Anforderung des zweiten Skripts
url-kodiert an den Server gesendet, der anhand dieser Daten und den
in einer DB gespeicherten Infos das zweite skript generiert.

>> da das im Gegensatz zum ersten nicht gecached werden darf/kann.
>
> Das kannst Du gar nicht wissen. Z.B. gibt es Browser mit
> Speichercaches.

Da das zweite skript immer über unterschiedliche URLs geladen wird,
muß es jeweils neu angefordert werden


> Wohlgemerkt: Ich bin _nicht_ gegen nachträgliche Fehlerbehandlung;
> sie sollte aber nur dann eingesetzt werden, wenn Fehler abgefangen
> werden sollen, die man nicht testen kann, d.h. die von Ralf erwähnten
> _Ausnahmen_. Das trifft hier nicht zu.

Ok, das habe ich mittlerweile verstanden und akzeptiert.

> Du benutzt Deinen Aussagen nach Exception-Behandung nur dafür, dass
> man als Benutzer nicht merkt, dass Du Fehler gemacht hast.

Im prinzip stimmt das ja, nur beziehe ich mich eben auf Fehler, die erst
dadurch entstehen, weil der Seitenbetreiber seinen Markup code ändert.

Das skript kann dann unmöglich etwas sinnvolles tun, stattdessen wird
auf der Seite ein Hinweis eingeblendet, daß eben ein Fehler aufgrund der
Änderung der HTML-Struktur aufgetreten ist, der in Kürze behoben wird.
Der benutzer weiß dann warum das skript nicht das tut was es soll, und
ich werden über die logs informiert.

Eigentlich halte ich das für sehr Benutzerfreundlich.

> Würdest Du auf
> den Zielplattformen und vor allem zur Laufzeit testen, entstünden gar
> keine Fehler, die man vor dem Benutzer verstecken müsste. Vielmehr
> könnte man ihm genau mitteilen, weshalb es nicht so funktioniert, wie
> es funktionieren soll.

Da der Benutzer i.d.R. keine Ahnung von HTML und dergleichen hat, würde
er mit den Fehlermeldungen nichts anfangen können.
#

Nochmals danke für die wertvollen tips!

Viele Grüße,
Andreas

.

Relevant Pages

  • Re: Fehlerbehandlung
    ... denn im Fehlerfalle soll das script ja ... Falls es nur deshalb nicht klappt weil der Benutzer JS ... Skript vom Server geladen, ... Skripte nocheinmal gemeinsam auf das dokument losgelassen. ...
    (de.comp.lang.javascript)
  • Re: Auslesen Lokaler Benutzer Funktioniert nicht
    ... > habe ich versucht aus Beispielen herzuleiten wie was funktioniert. ... > Es ist egal ob ich den Lokalen Benutzer von Hand anlege oder per Script. ... > der Fehler kommt immer. ...
    (microsoft.public.de.german.scripting.wsh)
  • Re: OE backup
    ... Internet Explorer Script Fehler ... Du hast nicht die nötigen Berechtigungen, ... Ich bin der einzige Benutzer des PC - somit auch Administrator ...
    (microsoft.public.de.german.windowsxp.sonstiges)
  • Re: netlogon script verhindert korrekte User-Anmeldung
    ... Script ausgefuehrt. ... Wenn der Benutzer an einem anderen rechner ist wird es auch ausgefuehrt. ... Dann ist der Fehler ja leicht: ...
    (microsoft.public.de.german.windows.server.active_directory)
  • Re: OE backup
    ... Internet Explorer Script Fehler ... zugreifen zu können. ... Ich bin der einzige Benutzer des PC - somit auch Administrator ...
    (microsoft.public.de.german.windowsxp.sonstiges)