testen ob "element has no properties"

[Kermit]

Hi,

wie kann ich im JS testen ob ei element überhaupt eine property hat?

if ( "element has no property" ?? ) {
  // mach was
}

vielen Dank und Gruß
Kermit

[Rouven]

Hello,

wie kann ich im JS testen ob ei element überhaupt eine property hat?

rührt dein Drang daher, eine Browserfehlermeldung NICHT zu bekommen? "has no properties" ist des Browsers Art dir zu sagen, dass das Objekt für ihn nicht existiert. Der entsprechende Vergleich dazu lautet
if (elem == null) {
   // do something
}

MfG
Rouven

[Kermit]

Hi,

nein, ich benutze prototype.js und auf eine bestimmte Seite schmeißt ein Fehler:
element has no properties
if ( element.offsetTop != null ) {
dein Beispiel funz also nicht.

prototype.js 1.6 line 2006
....
  cumulativeOffset: function(element) {
    var valueT = 0, valueL = 0;
    do {
if ( element.offsetTop != null ) {
     valueT += element.offsetTop  || 0;
}
      valueL += element.offsetLeft || 0;
      element = element.offsetParent;
    } while (element);
    return Element._returnOffset(valueL, valueT);
  },
....

[Kai345]

[latex]Moin![/latex]

nein, ich benutze prototype.js und auf eine bestimmte Seite schmeißt ein Fehler:
element has no properties
if ( element.offsetTop != null ) {
dein Beispiel funz also nicht.

Versuche es mit typeof

Cü,

Kai

[Kermit]

hab ich schon, gleicher Fehlermeldung

[Kermit]

mit try-catch funz
try {

} catch(e) {

}

[Cybaer]

Hi,

mit try-catch funz

Nein. Damit wird nur der Fehler, den Du machst versteckt. try-catch nimmt man *nur* dann, wenn es wirklich nicht anders geht (schon aufgrund seiner Nachteile). try-catch nimmt man hingegen nicht, nur weil man es einfach nicht richtig hinbekommt. Ist letztere Situation gegeben (wie hier), heißt die funzende Lösung nicht try-catch, sondern learning-understanding.

Gruß, Cybaer

[ZBuilder]

Hi,

mit try-catch funz

Nein. Damit wird nur der Fehler, den Du machst versteckt. try-catch nimmt man *nur* dann, wenn es wirklich nicht anders geht (schon aufgrund seiner Nachteile).

Welche Nachteile hat es denn und warum sollte man es nicht nehmen?
Ich nehme es immer aus bequemlichkeit, weil man sich damit viele Abfragen ersparen kann und es im Endeffekt auf genau dasselbe hinausläuft.

[Kermit]

weil es wahrscheinlich zu viel overhead erzeugt und somit der Script langsamer wird.

ich habe am Anfang falsch geprüft
mit element == null funz einwandfrei

[Cybaer]

Hi,

weil es wahrscheinlich zu viel overhead erzeugt und somit der Script langsamer wird.

Jep.

Gruß, Cybaer

[molily]

Hallo,

Welche Nachteile hat es denn und warum sollte man es nicht nehmen?
Ich nehme es immer aus bequemlichkeit, weil man sich damit viele Abfragen ersparen kann und es im Endeffekt auf genau dasselbe hinausläuft.

Super, dann kannst du ja einfach deinen ganzen Code in ein riesiges try-catch packen und brauchst gar nicht mehr nachdenken... ;)

So wird man aber nie ein komplexes und gleichzeitig kompatibles Script hinbekommen. JavaScripte leben davon, Abfragen zu machen. Im "Fehlerfall" brechen sie nicht einfach ab, sondern laufen bestenfalls weiter, versuchen Alternativen oder brechen zumindest *kontrolliert* ab, sodass der Autor den Fehler finden kann und der Anwender ein konsistentes Resultat sieht.

Das alles ist mit try-catch unmöglich oder viel schwerer möglich. try-catch ist für ganz andere Zwecke gedacht. Damit kann man sich nichts "ersparen"!

Mathias

[Rouven]

Hello,

element has no properties
if ( element.offsetTop != null ) {
dein Beispiel funz also nicht.

doch, tut es. Bitte lies genau: element has no properties - nicht offsetTop has no properties. Element hat also keine Eigenschaften auf die man zugreifen kann, aller Wahrscheinlichkeit nach weil element==null.

MfG
Rouven

[Christian Kruse]

你好 Kermit,

element has no properties
if ( element.offsetTop != null ) {
dein Beispiel funz also nicht.

Du hast es falsch angewendet:

  
cumulativeOffset: function(element) {  
     var valueT = 0, valueL = 0;  
  
     if(element == null) return;  
  
     do {  
       valueT += element.offsetTop  || 0;  
       valueL += element.offsetLeft || 0;  
       element = element.offsetParent;  
     } while (element);  
     return Element._returnOffset(valueL, valueT);  
   }  

再见,
 克里斯蒂安

[peterS.]

hallo Rouven, gruss Kermit,

wie kann ich im JS testen ob ei element überhaupt eine property hat?

rührt dein Drang daher, eine Browserfehlermeldung NICHT zu bekommen?
"has no properties" ist des Browsers Art dir zu sagen, dass das Objekt
für ihn nicht existiert. Der entsprechende Vergleich dazu lautet

if (elem == null) {
   // do something
}

ein vergleichender test auf die werte der primitiven typen [undefined] und
[null] sollte niemals mit dem vergleichsoperator [==] durchgefuehrt werden:

alert(null == null) // [true] - wie zu erwarten  
alert(window.undefined == null); // auch [true]  
  
alert(0 == false); // ebenfalls [true];

wenn schon unschoen, dann bitte mit dem identitaetsoperator [===]:

alert(null === null) // immer noch [true]  
alert(window.undefined === null); // richtigerweise [false]  
  
alert(0 === false); // ebenfalls richtigerweise [false];

besser waere es, einigermassen venuenftige "type detection" zu betreiben:

this.isUndefined = (function (obj) {  
  
  return (typeof obj == "undefined");  
});  
  
this.isNull = (function (obj) {  
  
//return ((typeof obj == "object") && (obj === null));  
  return ((typeof obj == "object") && (!obj));  
});

so long - peterS. - [e-mail]

[Cybaer]

Hi,

ein vergleichender test auf die werte der primitiven typen [undefined] und
[null] sollte niemals mit dem vergleichsoperator [==] durchgefuehrt werden:

Als bekennender Vertreter eines abwärtskompatiblen Programmierstils (sofern möglich) stößt mir dieses "niemals" immer sauer auf!

Ich mache mir auch lieber schon bei der Programmentwicklung Gedanken, welche Werte ich bei einer Abfrage/einem Vergleich zu erwarten habe. Bei einer Abfrage eines Object erwarte ich keine 0 oder Leerstring (bei einer Object-Eigenschaft sieht das schon anders aus).

Ansonsten stimme ich deinem Posting, insbes. was die type detection angeht, zu.

Gruß, Cybaer

[molily]

Hallo,

Der entsprechende Vergleich dazu lautet
if (elem == null) {
   // do something
}

Da reicht eigentlich if (elem) { ... }

Ich wüsst jetzt auf die Schnelle nicht, welchen signifikanten Unterschied == null macht (außer null == null ergibt true).

Aber das ist jetzt ziemlich allgemein, meistens will man zumindest typeof != undefined oder typeof == einen bestimmten Typ, wie gesagt.

Mathias