Re: Fehlerbehandlung
- From: Thomas 'PointedEars' Lahn <PointedEars@xxxxxx>
- Date: Tue, 13 Dec 2005 13:22:17 +0100
Andreas Born wrote:
> 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 ist doch Käse. Überprüfe, ob das Elementobjekt existiert, und sende
meinetwegen die Fehlermeldung, wenn es (das Objekt) das explizit nicht tut.
> 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).
Das funktioniert schon nicht zuverlässig. Das Element wird vermutlich
eingefügt, ob aber auch der referenzierte Script-Code ausgeführt wird,
steht auf einem anderen Blatt.
> 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.
Weshalb? Entweder das Script ist universell, dann spielt es keine Rolle,
ob ein Nutzer eine andere ID benutzt, da das dann _sein_ Fehler ist; eine
Änderung fände zu Lasten aller anderen Benutzer statt.
Oder es ist nicht universell, dann ist es erst recht erforderlich, dass der
Benutzer die Benennung einhält, die Du vorgibst. Für den unwahrscheinlichen
Fall, dass er das nicht tut, kannst Du Dich latür benachrichtigen lassen.
Dann reicht dafür aber auch ein Feature-Test aus, Du musst keinen Fehler
provozieren.
>>> 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.
Man braucht es doch aber dort gar nicht mehr. Umgekehrt wird ein Schuh
draus: Für das IE-DOM, d.h. IE 4.x, muss man Methoden entwickeln, die
ungefähr das tun, was DOM-Level-2-Methoden tun, indem man dort vorhandenen
proprietären aufruft.
Vgl. <URL:http://PointedEars.de/dhtml.js>
> 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.
Mozilla/5.0 Navigator ist genauso wie z.B. Mozilla Firefox oder
Netscape 6.0+ ein Gecko-basierter Browser. Opera unterstützt,
wie gesagt, Document::getElementById() seit Version 6.0.
<URL:http://www.opera.com/docs/specs/opera6/>
Und dann gibt es noch das KHTML-DOM (Konqueror, Safari), auch das
unterstützt Document::getElementById(). Andere weitverbreitete
DOMs als das IE-DOM, das Gecko-DOM, das Opera-DOM und das KHTML-DOM
gibt es derzeit nicht (im NN4-DOM, welches nur noch wenig verbreitet
ist, gibt es keine verlässliche Möglichkeit des "Script-Nachladens").
Zukünftige DOMs werden sich an einem dieser Quasi-Standards oder
eben am Standard W3C-DOM Level 2+ orientieren müssen, damit der
entsprechende UA konkurrenzfähig ist.
Siehe news:2235001.F5vJG4v19I@xxxxxxxxxxxxxx
> getElementById kann ich dann ja rauswerfen.
> Daneben habe ich u.a., insertAdjacentHTML,
DOM Level 2 Core:
Document::createElement()
Document::createTextNode()
Node::appendChild()
Überall überstützt, wo auch "Script-Nachladen" funktionieren _könnte_.
> id, className,
Standardisiert (DOM Level 2 HTML). Überall überstützt, wo auch
"Script-Nachladen" funktionieren _könnte_ (IE-DOM oder DOM Level 2).
> innerText.
IE-DOM. Node::textContent in DOM Level 3 Core, für neuere Gecko-basierte
Browser.
> Ich nehme an, daß diese im Gegensatz zu getElementById nicht
> überall definiert sind?
Richtig, da zum Teil proprietär. Was nicht heisst, dass man die definieren
muss.
>>> 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.
Natürlich nicht. Es macht aber deutlich, dass der Test Unsinn
ist, denn `myScript' existiert ja; der Wert ist nur `undefined'.
Wie Du ausserdem siehst, ist `typeof' ein Operator, keine Methode.
> In meinem Fall gibt es nur zwei Situationen:
> 1. Das Objekt wurde bereits von mir erstellt
Was auf unsaubere Programmierung hindeutet.
> 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.
Also bei sauberer Programmierung schlicht
var myScript = new objMyScript();
> So passt es wohl eher..?
>
> function objMyScript() {
> function start() {
> alert('started');
> }
> this.start = start;
> }
Ja.
> Oder ist das performanter...?
>
> function objMyScript() {
> this.start = function() {
> alert('started');
> }
> }
Das funktioniert erst ab JavaScript 1.3. Da aber kein Browser, der die
sonstigen verwendeten Techniken unterstützt, weniger als JavaScript 1.5,
oder JScript 1.0 versteht, ist das hier vernachlässigbar. Folglich kann
dieses Konstrukt benutzt werden.
>> 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.
Es kostet minimal, ja.
> Da im Fehlerfalle der akuelle Scriptbereich eh nicht weiter abgearbeitet
> werden soll, erscheint es mir sinnvoller, einfach einen Fehler zu werfen.
Du irrst.
> Ist zwar unsauber in der programmierung,
Ja.
> erscheint mir jedoch effektiver.
Das täuscht. Eine nachträgliche Fehlerbehandlung ist deutlich teurer,
sowohl was die Laufzeit als auch den Entwicklungsaufwand betrifft.
Merke: Unsaubere Programmierung ist niemals effizienter als saubere.
>>> 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.
Bei
if (typeof causeError == "function")
{
causeError();
}
passiert das auch 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).
Richtig. Deshalb macht man eine Fallunterscheidung, für den Fall, dass
es keine solche Methode gibt.
> Und die Überprüfung jedes einzelnen Objektes frisst wie schon erwähnt
> zuviel Performance.
Du irrst. Feature-Tests sind IMNSHO der einzig sinnvolle Weg,
DOM-Programmierung zu betreiben.
PointedEars
.
- Follow-Ups:
- Re: Fehlerbehandlung
- From: Andreas Born
- Re: Fehlerbehandlung
- From: Timo Stamm
- Re: Fehlerbehandlung
- References:
- Fehlerbehandlung
- From: Andreas Born
- Re: Fehlerbehandlung
- From: Thomas 'PointedEars' Lahn
- Re: Fehlerbehandlung
- From: Andreas Born
- Re: Fehlerbehandlung
- From: Thomas 'PointedEars' Lahn
- Re: Fehlerbehandlung
- From: Andreas Born
- Fehlerbehandlung
- Prev by Date: Zweites Fenster für Debug-Meldungen
- Next by Date: Re: Zweites Fenster für Debug-Meldungen
- Previous by thread: Re: Fehlerbehandlung
- Next by thread: Re: Fehlerbehandlung
- Index(es):
Relevant Pages
|
