Abfragen ob ein Objekt existiert

[Stoffel]

Hi,
ich will ein array anlegen, wenn es noch nicht existiert.
In Anlehnung an das HTML-Beispiel

  
      if (!document.images) ...  

habe ich folgendes geschrieben:

  
if (!Tab) {  
  alert ("Tab fehlt")  
  Tab=new Array()  
}  
else  
{  
 alert ("Tab vorhanden")  
}  

Da kommt aber die Fehlermeldung "Tab is not defined".
Diese Meldung wollte ich ja gerade umgehen!
Bitte helft einem Neuling auf die Sprünge.

[Cheatah]

Hi,

if (!document.images) ...

  
das Tolle an JavaScript ist, dass Eigenschaften eines (existierenden) Objektes immer existieren und im Zweifel halt nur undefined sind.  
  

> ~~~javascript
  

> if (!Tab) {  
> 

Variablen hingegen existieren nicht zwingend. Das Tolle an JavaScript ist aber, dass (globale) Variablen immer Eigenschaften des window-Objektes sind.

Cheatah

[Stoffel]

Hi,

if (!Tab) {

  
  
so hatte ich es doch.  
  

>   
> Variablen hingegen existieren nicht zwingend. Das Tolle an JavaScript ist aber, dass (globale) Variablen immer Eigenschaften des window-Objektes sind.  
  
Das verstehe ich leider nicht.  

[Cybaer]

Hi,

Variablen hingegen existieren nicht zwingend. Das Tolle an JavaScript ist aber, dass (globale) Variablen immer Eigenschaften des window-Objektes sind.
Das verstehe ich leider nicht.

Genauso wie "images" bei document.images ein Unterobjekt von document ist, so ist eine globale(!) Variable ein Unterobjekt von window. myGlobalVar=10 kann also auch geschrieben werden als window.myGlobalVar=10 bzw. in Klammernotation window["myGlobalVar"]=10.

Gruß, Cybaer

[Cybaer]

Hi,

Bitte helft einem Neuling auf die Sprünge.

Sofern die "einfache" Abfrage nicht geht (s. Cheatah), kann man mit typeof() abfragen: if(typeof(Tab)=="undefined) ...

Gruß, Cybaer

[Stoffel]

Hi,

Sofern die "einfache" Abfrage nicht geht (s. Cheatah), kann man mit typeof() abfragen: if(typeof(Tab)=="undefined) ...

Also doch lieber gleich diese Variante oder?

[Cybaer]

Hi,

Also doch lieber gleich diese Variante oder?

Wie Du magst.

Die Kurzversion ist halt kürzer ;), und deswegen vermutlich auch beliebter (wenn man mal davon absieht, daß es typeof() ohnehin erst ab JS 1.1 gab - vorher gab es nur die Kurzversion).

Gruß, Cybaer

[Don P]

Hallo,

Die Kurzversion ist halt kürzer ;), und deswegen vermutlich auch beliebter

Aber sie funktioniert halt nicht zuverlässig (siehe OP), so dass man mindestens ein Objekt nennen sollte, also z.B. if( !this.Tab ){...} oder auch if( !window.Tab ){...}, falls sicher eine globale Variable "Tab" gemeint ist.

Gruß, Don P

[Cybaer]

Hi,

Aber sie funktioniert halt nicht zuverlässig (siehe OP),

Diese Methode funktioniert absolut zuverlässig.

Aber man sollte a) vielleicht ein paar Grundlagen kennen und b) nicht Sachen für etwas verwenden, für das sie nicht gedacht sind.

Gruß, Cybaer

[Don P]

Hallo,

Diese Methode funktioniert absolut zuverlässig.

Welche jetzt? Es geht doch um die if(!x){...}-Bedingung, die einen Fehler auslöst (in FireBug), wenn x nicht definiert ist. Und das nennst du zuverlässig?

Aber man sollte a) vielleicht ein paar Grundlagen kennen und b) nicht Sachen für etwas verwenden, für das sie nicht gedacht sind.

...und c) nicht polemisieren. Grundlagen sind mir natürlich absolut fremd ;-)
und welche "Sachen" du meinst, ist mir daher auch völlig unklar.

Gruß, Don P

[Cybaer]

Hi,

Welche jetzt? Es geht doch um die if(!x){...}-Bedingung, die einen Fehler auslöst (in FireBug), wenn x nicht definiert ist. Und das nennst du zuverlässig?

Ja - wenn man sie nur dafür einsetzt, wofür sie gedacht ist bzw. seit jeher verwendet wird (und nicht als typeof()-Ersatz).

...und c) nicht polemisieren. Grundlagen sind mir natürlich absolut fremd ;-)

Die Anmerkung war *in keinster Weise* persönlich gemeint! =:-)

Gruß, Cybaer

[Don P]

Hallo,

Sofern die "einfache" Abfrage nicht geht (s. Cheatah), kann man mit typeof() abfragen: if(typeof(Tab)=="undefined) ...

Also doch lieber gleich diese Variante oder?

Noch einfacher ist:

Tab = this.Tab || [];

Denn Cheatah hat ja das entscheidende genannt:

dass Eigenschaften eines (existierenden) Objektes immer existieren und im Zweifel halt nur undefined sind.

und

dass (globale) Variablen immer Eigenschaften des window-Objektes sind.

Du musst also nur deine evtl. undefinierte Variable als Eigenschaft des gewünschten Objekts, z.B. des this-Objekts, notieren.

Der Default-Operator || sorgt dafür, dass, falls die Variable undefiniert ist, das neue Array oder was immer du haben willst, zugewiesen wird – [] ist synonym mit new Array(), {} mit new Object().

Eine andere Variante wäre noch:

try{!Tab}catch(e){if(e)this.Tab=[]}

Die ist aber dagegen recht umständlich.

Gruß, Don P

[Cybaer]

Hi,

Noch einfacher ist:

Du meinst: unzuverlässiger?

Ob das klappt hängt (noch stärker) von der JS-Version ab, vor allen Dingen aber, worauf sich this bezieht.

try{!Tab}catch(e){if(e)this.Tab=[]}

try...catch ist schon wg. des entstehenden Overheads nur für Testzwecke geeignet, und natürlich dann, wenn es keine andere Möglichkeit gibt. Für diesen Fall gibt es eine andere Möglichkeit: typeof() - die ist sogar explizit für diese Problemstellung gedacht.

Gruß, Cybaer

[Don P]

Hallo,

Noch einfacher ist:

Du meinst: unzuverlässiger?

Ob das klappt hängt (noch stärker) von der JS-Version ab

Wieso das denn? Der ||-Operator existiert meines Wissens unverändert seit der Erfindung von JavaScript, ebenso die literale Notation von Arrays.

vor allen Dingen aber, worauf sich this bezieht.

Das stimmt natürlich. Ist aber im genannten Beispiel (OP) bekannt, und man weiß ja beim coden, worauf es sich bezieht, bzw. sollte es immer wissen.

Übrigens:

dass (globale) Variablen immer Eigenschaften des window-Objektes sind

(Zitat Cheatah, der damit anscheinend seinem Nick alle Ehre macht ;-))

stimmt offensichtlich nicht. Es müsste richtig heißen, dass (globale) Variablen immer Eigenschaften des window-Objektes *werden*, wenn man sie zum ersten mal als lvalue in ein einer Zuweisung verwendet.

'undefined' sehe ich auch als Wert an, und es wäre mir wesentlich lieber, wenn Cheatah da recht hätte und undefinierte Variablen keinen Fehler auslösten, wenn man sie undeklariert verarbeiten will. Oder ist es am Ende gar kein javascript-Fehler, sondern nur einer von FireBug, der das zu unrecht als Fehler ansieht?

Gruß, Don P

[Cybaer]

Hi,

Wieso das denn? Der ||-Operator existiert meines Wissens unverändert seit der Erfindung von JavaScript, ebenso die literale Notation von Arrays.

Ich *glaube*, daß die literale Notation erst später kam. Ich wollte es immer mal überprüfen (und wenn ja: ab welcher Version), bin aber nie dazu gekommen ... :)

Das stimmt natürlich. Ist aber im genannten Beispiel (OP) bekannt, und man weiß ja beim coden, worauf es sich bezieht, bzw. sollte es immer wissen.

Eben, genau das *sollte* man! Wie bei der Kurzform ja (eigentlich) auch. :)

stimmt offensichtlich nicht. Es müsste richtig heißen, dass (globale) Variablen immer Eigenschaften des window-Objektes *werden*, wenn man sie zum ersten mal als lvalue in ein einer Zuweisung verwendet.

var myGlobalVar; ist keine Zuweisung.

'undefined' sehe ich auch als Wert an, und es wäre mir wesentlich lieber, wenn Cheatah da recht hätte und undefinierte Variablen keinen Fehler auslösten, wenn man sie undeklariert verarbeiten will. Oder ist es am Ende gar kein javascript-Fehler, sondern nur einer von FireBug, der das zu unrecht als Fehler ansieht?

? Ich sehe kein Fehlverhalten - auch nicht im FireBug:

if(!myGlobalVar) { alert("myGlobalVar is not defined!"); }  

~~~ erzeugt einen Fehler (egal ob FireBug oder nicht).  
  
`if(!window.myGlobalVar) { alert("myGlobalVar is not defined!"); }`{:.language-javascript} hingegen funktioniert wie fehlerfrei.  
  
  
Gruß, Cybaer  

-- 
Man kann doch sehr leicht jenen tugendhaften Menschen begegnen, (...) die eine Art "unkrümmbaren Zeigefinger" besitzen, der ständig den kalten Wind des Rechthabens ausströmt. (Wolfgang Huber, Bischof)  
  
Die Tugend jagt nicht den Teufel, sondern den Sündhaften. Damit wird sie zum Terror. (Hans-Ulrich Jörges, Journalist)

[Cybaer]

Hi,

Ich *glaube*, daß die literale Notation erst später kam. Ich wollte es immer mal überprüfen (und wenn ja: ab welcher Version), bin aber nie dazu gekommen ... :)

So, jetzt *weiß* ich, daß die literale Notation erst später kam. ;)

JS 1.1 kennt die literale Notation definitiv noch nicht. Ich *glaube*, daß die literale Notation mit JS 1.3 eingeführt wurde (ein Glaube, basierend auf einer diffusen "Gefühlslage" und nicht getrübt von Faktenwissen irgendwelcher Art! ;-> - kann also auch JS 1.2 oder 1.5 gewesen sein).

Gruß, Cybaer

[Don P]

High ;)

Es müsste richtig heißen, dass (globale) Variablen immer Eigenschaften des window-Objektes *werden*, wenn man sie zum ersten mal als lvalue in ein einer Zuweisung verwendet.

var myGlobalVar; ist keine Zuweisung.

Nein, es ist eine Deklaration, und zwar in der Regel für eine *lokale* Variable (außer man notiert das im globalen scope). Was hat diese deine Feststellung also mit meiner Aussage über undeklarierte Variablen zu tun, die, als lvalue verwendet, global werden?

? Ich sehe kein Fehlverhalten - auch nicht im FireBug:

if(!myGlobalVar) { alert("myGlobalVar is not defined!"); }

>   
> `if(!window.myGlobalVar) { alert("myGlobalVar is not defined!"); }`{:.language-javascript} hingegen funktioniert wie fehlerfrei.  
  
Das ist ja gerade das Fehlverhalten! Ich glaube gelernt zu haben, dass man die Existenz eines Objekts o einfach abfragen kann mit if(o)..., und dank dieses Threads stellt sich jetzt heraus, dass das so nicht stimmt.  
  
Lediglich die Existenz einer Methode oder einer Eigenschaft eines existierenden Objekts kann mit dieser Kurzform abgefragt werden oder anders ausgedrückt: window als das globale Objekt wird nicht automatisch als das parent-Objekt einer undeklarierten Variablen angesehen, so dass die Kurzform if(o) leider zu einem Fehler führt, wenn typeof o === 'undefined' gilt. Ich halte das für einen Fehler in der Sprache.  
  
Gruß, Don P  

[Cybaer]

Hi,

Ich halte das für einen Fehler in der Sprache.

JS enthält viele Fehler.

Allerdings kann JS unter keinen Umständen "einfach so" die Existenz eines Unterobjektes behandeln, wenn das Hauptobjekt unklar ist.

Oder anders: Bei if(Tab) kann JS (zumindest innerhalb einer Funktion) nicht wissen, ob es sich um ein nicht-existentes Unterobjekt von window handelt, oder um eine nicht-existente lokale Variable.

Einen Fehler in der Systematik kann ich hier zumindest nicht feststellen, denn die unterschiedliche Reaktion läßt sich innerhalb der JS-Regeln auch begründen.

Gruß, Cybaer

[Don P]

Hallo,

Oder anders: Bei if(Tab) kann JS (zumindest innerhalb einer Funktion) nicht wissen, ob es sich um ein nicht-existentes Unterobjekt von window handelt, oder um eine nicht-existente lokale Variable.

Stimmt, aber das ist doch auch völlig unwichtig. Wenn etwas im Universum nicht existiert, dann reicht das doch eigentlich als Information. Da muss man doch nicht noch zusätzlich wissen, dass in der Milchstraße auch nicht existiert, in unserem Sonnensystem auch nicht und auch nicht auf der Erde. Denn wenn es dort irgendwo in der Hierarchie existieren würde, dann würde if(es) eben true ergeben, und als das nächstliegende in der Hierarchie angesprochen, basta.

Einen Fehler in der Systematik kann ich hier zumindest nicht feststellen, denn die unterschiedliche Reaktion läßt sich innerhalb der JS-Regeln auch begründen.

Mag sein, dass da noch etwas ist, was ich jetzt nicht bedacht habe. Mir kommt es jedenfalls so vor, als ob hier die Regel, dass im Zweifelsfall immer das globale Objekt herhalten soll, nicht konsequent umgesetzt ist.

Gruß, Don P

[Cybaer]

Hi,

Nein, es ist eine Deklaration,

Merkste was?

und zwar in der Regel für eine *lokale* Variable (außer man notiert das im globalen scope).

Den Teil des Satzes kann (und sollte) man IMHO getrost vergessen.

Was hat diese deine Feststellung also mit meiner Aussage über undeklarierte Variablen zu tun, die, als lvalue verwendet, global werden?

Du brauchst keine Zuweisung, um die entsprechende window-Eigenschaft "bekannt" zu machen. Eine Deklaration reicht bereits. Daß JS nicht wie andere Programmiersprachen dazu zwingt, Variablen vorab zu deklarieren, ist IMHO nicht nachteilig - wenn man weiß, was man tut, und damit auch weiß, wenn man besser deklarieren sollte (also: eigentlich immer ;-)).

Gruß, Cybaer

[Don P]

Hallo,

Nein, es ist eine Deklaration,

Merkste was?

Ich weiß das, aber du hast es anscheinend nicht bemerkt, sonst hättest du das nicht als Argument gebracht.

Du brauchst keine Zuweisung, um die entsprechende window-Eigenschaft "bekannt" zu machen. Eine Deklaration reicht bereits. [...]

Mann, jetzt wird's aber müßig. Dass man Variablen deklarieren kann und sollte, auch globale, ist doch völlig klar. In diesem ganzen Thread geht es aber einzig und allein darum, was u.U. passiert, wenn man sie *nicht* deklariert hat!

In meiner Aussage

dass (globale) Variablen immer Eigenschaften des window-Objektes *werden*, wenn man sie zum ersten mal als lvalue in ein einer Zuweisung verwendet

steht doch mit keiner Silbe, dass Variablen *nur* unter diesen Umständen global werden, was du mir jetzt aber unterstellen willst.

Also lassen wir das jetzt, ok?

Gruß, Don P

[Joachim]

Hi,

if (!Tab) {
  alert ("Tab fehlt")
  Tab=new Array()
}
else
{
alert ("Tab vorhanden")
}

eine weiter Möglichkeit wäre:
try {

if (!Tab) {

} else {

}

} catch(err) {
    alert(err)
}

hierbei wird der Fehler abgefangen, und kann bei Bedarf im alert ausgegeben werden.

Gruesse, Joachim

[Cybaer]

Hi,

eine weiter Möglichkeit wäre:

Nochmal der Hinweis, daß try...catch in der normalen Programmgestaltung nichts zu suchen hat. Es ist zu Entwicklungszwecken gedacht, und wenn es *gar nicht* anders geht. Und hier sollte man die Methode nehmen, die dafür gedacht ist ... (sollte man eigentlich immer machen ;-)).

Gruß, Cybaer

[Daniel Thoma]

Hallo Cybaer,

Nochmal der Hinweis, daß try...catch in der normalen Programmgestaltung nichts zu suchen hat.

try-catch hat im regulären Programmablauf nichts zu suchen, d.h. wenn alle Voraussetzungen erfüllt sind, um die vorgesehene Aufgabe zu erfüllen, sollte keine Exception geworfen werden.
try-catch ist aber ansonsten sehr wohl gedacht um Fehler- und  Ausnahmesituationen einfacher handhabend zu können. Exceptions sind also nicht nur für Fehler zuständig, die gar nicht erst auftreten können, sondern auch für "unerwartete" Ereignisse. Bspws das eine Datei nicht lesbar ist, ein Server nicht antwortet oder eben ein Objekt nicht verfügbar ist.

So etwas wäre ein ganz regulärer Anwendungsfall:

  
try {  
  // tue verschiedene dinge mit objekten die es villeicht nicht gibt  
} catch (err) {  
  // versuche ohne diese objekte auszukommen  
}  

Wenn man nicht nur ein Objekt sondern mehrere benötigt, kann das sehr viel eleganter sein. Außerdem ist es einfacher, die Fehlerbehandlung den Stack hoch zu delegieren, falls man das möchte.

Was man hingegen nicht tun sollte ist so etwas:

  
try {  
  var i = 0;  
  while (true) {  
    i++;  
    tuewas(array[i]);  
  }  
} catch (err) {  
  
}  

Grüße

Daniel

[Stoffel]

Hi,
"da steh ich nun, ich armer Tor, und bin so klug als wie zuvor"
Was ist nun die ultimativ richtige Lösung?

[Don P]

Hallo,

Nimm meine (immer ein Objekt mit angeben) oder die von Cybaer (typeof == 'undefined' abfragen, falls du mit antiquierten javascript-Versionen bei den Anwendern rechnest), aber definitiv nicht die try...catch-Variante.

Gruß, Don P

[Don P]

Hallo,

Noch ein Tipp:
typeof liefert leider manchmal falsche Ergebnisse (typeof null === 'object') und manchmal wenig aussagekräftige (typeof [] === 'object').

Die Prüfung auf 'undefined' ist aber unbedenklich.

Gruß, Don P

[Cybaer]

Hi,

Hi,
"da steh ich nun, ich armer Tor, und bin so klug als wie zuvor"
Was ist nun die ultimativ richtige Lösung?

Wenn mehrere Möglichkeiten (funktional) gleichberechtigt nebeneinander existieren, solltest Du (insbesondere als Anfänger) immer die Lösung nehmen, die am wenigsten problematisch ist.

Und das ist in diesem Fall if(typeof(Tab)=="undefined") { Tab=new Array(); }

Sie funktioniert am längsten (seit JS 1.1) und völlig unabhängig vom Umstand, ob Tab nun eine globale oder lokale Variable ist.

Gruß, Cybaer

[Stoffel]

Bis hierher mal danke an alle Beteiligten.
Jetzt ist gleich eine neue Frage aufgetaucht.
Wenn ich abfrage:

Wenn die Variable nicht existiert oder deren Wert == 'x' ist, dann Aktion1
also:

if (typeof(v) == 'undefined' || v == 'x') {
   ........
}

ist dann gewährleistet, dass von links nach rechts verarbeitet wird, also nicht erst die Abfrage auf 'x' erfolgt?
Wenn nicht, müsste man wohl mit
if ....
   if .....
arbeiten.

[Don P]

Hallo,

Wenn die Variable nicht existiert oder deren Wert == 'x' ist, dann Aktion1
also:

if (typeof(v) == 'undefined' || v == 'x') {
   ........
}

ist dann gewährleistet, dass von links nach rechts verarbeitet wird, also nicht erst die Abfrage auf 'x' erfolgt?

Ja, das ist definitiv so. Wenn der linke Vergleich (typeof(v) == 'undefined') zu true evaluiert, dann wird der rechte (v == 'x') völlig ignoriert, kann also auch keinen Fehler auslösen.

Gruß, Don P

[Stoffel]

Hi,
vielen Dank!
Soll ich eigentlich mit weiteren Fragen, die ganz anderer Natur sind, jeweils einen neuen Thread aufmachen?
Z.B. folgendes Problem(chen):
Beim Verlassen eines Feldes wird es geprüft und wenn es fehlerhaft ist, wird mit alert eine Fehlermeldung ausgegeben.
Wenn ich auf den "Senden"-Button klicke (und aus einem derartigen Feld komme),
kommt wie beschrieben das Fehlerfenster, aber unmittelbar danach ein zweites Fenster aus der Gesamtformularprüfung nach dem Absenden. Es sind also zwei Fehlerfenster offen.
Ich war der Meinung, dass das Programm erst weiterläuft, wenn man das erste Fenster schliesst.
Kann man das irgendwie erreichen?

[Don P]

Hallo,

Soll ich eigentlich mit weiteren Fragen, die ganz anderer Natur sind, jeweils einen neuen Thread aufmachen?

Ja, das würde ich raten. Dieser Thread ist ja jetzt erledigt und kann von mir aus so, wie er ist, im Archiv landen.

Danke noch für deine Frage am Anfang. Ich hatte mir das Ganze noch nicht so verdeutlicht, wie jetzt in diesem Thread. Solche grundsätzlichen Dinge interessieren mich nämlich, und ich bin wirklich überrascht, was dabei herauskam. :-)

Gruß, Don P