Re: Fehlerbehandlung
- From: Thomas 'PointedEars' Lahn <PointedEars@xxxxxx>
- Date: Fri, 16 Dec 2005 11:41:55 +0100
Timo Stamm wrote:
> Thomas 'PointedEars' Lahn wrote:
>> Andreas Born wrote:
>>>Thomas 'PointedEars' Lahn wrote:
>>> 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.
>
> Die Fehlermeldung geht dann aber nur an den Benutzer, nicht an den
> Entwickler.
Falsch, lies nochmal. Es mir nicht darum, keine Fehler an den Entwickler
zu senden. Es geht mir darum, dass man keine Fehler aufgrund inkompatiblen
Codes und fehlender Tests sowohl zur Entwicklungs- als auch zur Laufzeit
provozieren sollte.
Wenn _dann_ das Script trotzdem nicht funktioniert, weil der _Test_ negativ
ausfällt, kann meinetwegen das Problem an den Entwickler gemeldet werden.
(Auch, wenn ich wie gesagt keinen grösseren Sinn darin sehe, mehr dazu
unten.)
> Thomas' Intention, client-seitige Fehler zu loggen ist doch
^^^^^^
> nicht falsch für diese Anwendung.
Du verwechselst da was :)
> Ich würde alle Fehler fangen
Dazu müsste man das _gesamte_ Script in try...catch stecken, was das
Debugging erheblich erschwert und das Script inkompatibel zu Engines
macht, die try...catch nicht unterstützten. Mit dem von mir
vorgeschlagenen eval()-Konstrukt ist es dann nämlich auch Essig,
weil das (und die vorherige Zuweisung an den Event-Listener `onerror')
schon wieder eine Anweisung ist, die Fehler verursachen kann.
> und Fragen ob der Fehler an den Entwickler gesendet werden soll.
> Details zum Fehler braucht der Benutzer nicht sehen.
Prima. Jetzt belästigen wir also auch noch den Benutzer, nur weil wir
inkompetent genug sind, schlechten Script-Code auf ihn loszulassen?
Das ist grober Unfug!
> Wenn sich die Fehler auf falsche/fehlende Elemente beschränken, könnte
> man die Seiten regelmässig auf Änderungen überprüfen.
Ja, aber wie gesagt: ist die Anwendung universell, zieht eine Änderung
des Scripts, um der Änderung des Markups bei einem Benutzer zu genügen,
die Nichtfunktion bei allen anderen Benutzern nach sich. Wie will man
da entscheiden, was das Richtige ist? Selbst wenn 51% der Benutzer die
Änderung vornehmen, würde man als Entwickler dann immer noch 49% der
Benutzer verprellen, weil bei denen das Script dann nicht mehr
funktioniert. Entsprechend viele Nichtfunktionen müsste man dann loggen.
Ist die Anwendung nicht universell, sondern nur für einen Kunden, so ist
vom Entwickler ein Standard der Element-Benennung vorzugeben, der vom
Kunden einzuhalten ist. Und kein Kunde wird für jede Umbenennung
Entwicklungskosten einkalkulieren; da ändert man lieber das Markup, was
ja nun wirklich auch nicht allzu schwierig ist.
> Wenn der javascript-Code generiert wird lässt sich server- und
> client-Seite eines Plugins in einem Rutsch schreiben.
Du schreibst offensichtlich über Dinge, die Du nicht ganz verstanden hast.
Beispielsweise will Andreas den Code, der hier clientseitig ausgeführt
werden soll, auch clientseitig dynamisch einfügen (durch Hinzufügen eines
script-Elements, was aber wie gesagt unzuverlässig ist). Es passiert also
gar nichts serverseitiges.
AIUI geht es hier um kein Plugin, sondern um eine Firefox-Erweiterung bzw.
um ein Bookmarklet. Selbst wenn, führt ein Plugin an sich in aller Regel
serverseitig keinen Code aus; das tut nur ein Request seiner Anwendung
(z.B. ein Flash-Spiel für das Flash-Player-Plugin, welches Highscores in
einer Datenbank auf einem Server speichert).
PointedEars
.
- Follow-Ups:
- Re: Fehlerbehandlung
- From: Timo Stamm
- Re: Fehlerbehandlung
- From: Andreas Born
- Re: Fehlerbehandlung
- From: Thomas 'PointedEars' Lahn
- 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
- Re: Fehlerbehandlung
- From: Thomas 'PointedEars' Lahn
- Re: Fehlerbehandlung
- From: Timo Stamm
- Fehlerbehandlung
- Prev by Date: Re: Fehlerbehandlung
- Next by Date: Re: Fehlerbehandlung
- Previous by thread: Re: Fehlerbehandlung
- Next by thread: Re: Fehlerbehandlung
- Index(es):
Relevant Pages
|
Loading