Bei den meisten EL-Prüfprogrammproblemen kann die Wertigkeit mit Fehler, Warnung oder keine angepasst werden. Bei der Wertigkeit keine wird der Fehler zu Berichtszwecken tatsächlich ignoriert.
In der folgenden Tabelle wird jedes Problem gezeigt, dessen Wertigkeit angepasst werden kann und deren Auswirkungen werden erklärt:
Beschreibung | Beispiel | Erläuterung |
---|---|---|
Allgemeiner Syntaxfehler | #{* x} | Syntaxfehler sind eine allgemeine Verletzung der EL-Sprache. Im Beispiel erwartet der Multiplikationsoperator '*' zwei Operanden, es wird aber nur einer (x) zur Verfügung gestellt. |
Leerer EL-Ausdruck | #{} | Gibt an, dass kein Ausdruck zur Verfügung gestellt wurde. |
Beim Ausdruck fehlt die schließende eckige Klammer. | #{x + 5 | Gibt an, dass eine schließende eckige Klammer '}' hinzugefügt werden muss, wie in "#{x + 5}" |
Anwendung des Operators auf das Methodenbinding. | #{bean.action * 5} | Falls bean.action eine Methode "action()" bei der Bean angibt, ist es keine gültige EL, das Resultat als einen Wert zu behandeln. Im Beispiel versucht die Multiplikationsaktion 'mal 5' die Behandlung als Wert. |
Für die mit Punkten gekennzeichneten Eigenschaftennamen sollte Bereichssyntax ([]) verwendet werden. | #{property.name.foo} | Fallsname.foo der Schlüssel eines Werts in einem Eigenschaftspaketindex für property, ist, empfiehlt die EL-Spezifikation (obschon dies nicht erforderlich ist), dass Sie dies stattdessen als property['name.foo'] ausdrücken, um die Tatsache zu betonen, dass name.foo ein Schlüssel in einer Zuordnung ist, im Gegensatz, beispielsweise zu einer Bean-Eigenschaft. |
Variable wurde nicht gefunden. | #{bean property} | Wenn bean nicht als eine Variable aufgelöst werden kann, wird dieser Fehler markiert. Da die Entwicklungszeit nicht zu 100% über die zur Laufzeit aktiven Variablen Bescheid weiß, kann eine gelegentliche Unterdrückung nützlich sein, um falsche es nützlich sein, um Fehlalarme zu reduzieren. |
Member wurde nicht gefunden. | #{bean property} | Wenn property nicht als eine Variable von bean, aufgelöst werden kann, wird dieser Fehler markiert. Beispielsweise falls bean eine Klasse ohne Methoden getProperty/setProperty ist. Obschon es sehr unwahrscheinlich ist, dass diese Prüfung Fehlalarme auslöst, kann es sinnvoll sein, dies zu ignorieren, wenn Sie viele verschiedene Variablenquellen, wie z. B. Tags, verwenden. |
Property ist temporär. | #{property.name} | Dieses Problem tritt auf, da EL das Zeichen '.' in Schlüsselnamen zulässt (wie z. B. in bean['x.y'], aber auch zulässt, dass es als Member-Operator (wie in bean.property) verwendet wird. Dies kann zur Verwirrung des Benutzers führen, besonders in Fällen wie dem obigen Beispiel, in dem property eine Zuordnung darstellt, die durch ein Ressourcenpaket (d. h. eine Eigenschaftendatei) gestützt wird. Im Falle des Beispiels nehmen wir an, dass es ein Schlüssel für name.foo ist. Die Anweisung property.name mag dann aussagekräftig erscheinen, selbst wenn sie keinen Schlüssel im Paket hat und in einem Nullwert oder einer Laufzeitausnahmebedingung resultiert. |
Probleme durch implizite Typumwandlung von Zahlen für Binäroperationen. | #{5 * true} | Einige Binäroperatoren (wie '+', '-', '*', '/' und mod, die zwei Operanden wie in x + y) nutzen, setzen voraus, dass beide Operanden vor Anwendung der Operation in Zahlen umgewandelt werden. Im Beispiel ist true (wahr) ein boolesches Literal, dass keine gültige Umwandlung in einen numerischen Wert hat (obschon einige Implementierungen eine Umwandlung in C-ähnlicher Weise erzwingen). Solche Umwandlungsfehler verursachen normalerweise Laufzeitausnahmebedingungen. Beachten Sie, dass Variablen (d. h. bean.booleanProperty) ebenfalls dieselben Umwandlungsprobleme haben; sie sind nicht auf Literale beschränkt. |
Probleme durch implizite Typumwandlung von Booleschen Werten für Binäroperationen. | #{myBean.integerProperty && true} | Einige Binäroperatoren (wie &&, ||) setzen voraus, dass beide Operanden vor Anwendung der Operation in boolesche Werte umgewandelt werden können. Im Falle des Beispiels ist myBean.integerProperty eine Bean-Eigenschaft des Typs ganze Zahl. EL erlaubt eine Umwandlung von numerischen Typen in Boolesche (obschon einige Implementierungen eine C-ähnliche Umwandlung erzwingen). |
Keine impliziten Typumwandlungen für Binäroperation verfügbar. | #{myBean.stringArrayProperty >= myBean.booleanProperty} | Wenn einem Binäroperator wie >= Operanden zugewiesen werden, von denen keiner aussagekräftig so umgewandelt werden kann, dass der Typ der Operanden abgeleitet werden kann, wird dieser Fehler angezeigt. Im Beispiel ist weder stringArrayProperty noch booleanProperty ein gültiger Wert, der unter Verwendung des Operators ">=" vergleichbar ist. |
Implizite Typumwandlung von Literal in Zahl. | #{'a' + 'b'} | EL lässt manchmal zu, dass Zeichenfolgewerte in Zahlen umgewandelt werden. Beispielsweise ist #{'5' + '6'} gültig, da sowohl '5' als auch '6' unter Verwendung von 'Long.valueOf()' in Zahlen umgewandelt werden können. Jedoch sind ähnliche Umwandlungen nicht gültig, wenn eine solche Konvertierung nicht vorgenommen werden kann. Zur Entwicklungszeit können wir einer solchen ungültigen Konvertierung nur sicher sein, wenn der fragliche Wert ein Literal ist (falls er eine Variable ist, wissen wir dies im allgemeinen erst zur Laufzeit). Im Beispiel können wir sicher sagen, dass weder 'a' noch 'b' in einem vom Operator '+' erwarteten numerischen Typ konvertiert werden kann. |
Probleme durch implizite Typumwandlung von Zahlen für monadische Operationen | #{-myBean.mapProperty} | Der monadische Minusoperator erwartet von seinen Operanden, dass sie in einen numerischen Typ umgewandelt werden können, bevor die Operation angewendet wird. Im Beispiel ist myBean.mapProperty vom Typ 'java.util.Map', für den es keine gültige Umwandlung in eine Zahl gibt. |
Probleme durch implizite Typumwandlung von Booleschen Werten für monadische Operationen | #{!myBean.mapProperty} | Der monadische Operator 'not' erwartet von seinen Operanden, dass sie in einen Booleschen Typ umgewandelt werden können, bevor die Operation angewendet wird. Im Beispiel ist myBean.mapProperty vom Typ 'java.util.Map', für den es keine gültige Umwandlung in einen Booleschen Typ gibt. |
Implizite Typumwandlung von Zeichenfolge für monadische Operation nicht garantiert. | #{-myBean.stringProperty} | Zeichenfolgenumwandlungen in Zahlen, wie sie von monadischen Minusoperatoren erwartet werden, sind, je nach Wert der Zeichenfolge, nicht garantiert. Dieses Problem markiert solche möglichen Probleme. |
Beide Operanden sind Null. | #{null + null} | Wenn beide Operanden Null sind, ist der resultierende Wert konstant und kann manuell komprimiert werden (ersetzt durch die Literalkonstante), um den Code zu reduzieren. |
Auswertung des Binärausdrucks führt stets zu demselben Wert. | #{x + 5 * 4} | Wenn beide Argumente eines Binärausdrucks Literale sind, kann die Operation zur Entwicklungszeit komprimiert werden. Beispielsweise kann dieser Ausdruck auf #{x+20} vereinfacht werden. |
Auswertung des Gleichheitsausdrucks mit Null führt stets zu demselben Wert. | #{myBean.integerProperty == null} | EL-Auswertung von Gleichheitsausdrücken ('==', '!=', '>=' etc.) mit Null führt stets zu demselben Wert. Generell resultiert Ungleichheit in 'true' (wahr), Gleichheit und alle relationalen Operatoren resultieren in 'falsch' (false). |
Auswertung des Auflistungsausdrucks führt stets zu demselben Wert. | #{myBean.coins == 'notAValue'} | Da die möglichen Werte einer Auflistung (Java 5 und höher) sind zur Kompilierzeit bekannt, wir können also Vergleiche ausschließen, von denen wir wissen, dass sie stets in demselben Wert resultieren. Im Beispiel ist notAValue kein Member der Auflistung 'Coins', sodass wir wissen, dass die Gleichheit niemals 'true' sein kann. |
Auswertung des monadischen Ausdrucks führt stets zu demselben Wert. | #{empty 'notEmpty'} | Die monadischen Operatoren haben Operanden, bei denen zur Entwicklungszeit festgestellt werden kann, dass die Auswertung stets denselben Wert ergibt. Im Beispiel resultiert der Operator empty immer in 'falsch' (false), wenn er auf eine Zeichenfolge angewendet wird, die ungleich Null und nicht leer ist. |
Leerer Operator wird stets mit 'falsch' (false) für Typ ausgewertet. | #{empty myBean.integerProperty} | Die Auswertung des Operators empty ergibt stets 'falsch' (false), es sei denn, dass sein Operand ein Nullwert, eine leere Zeichenfolge oder vom Typ Bereich, Zuordnung oder Objektgruppe ist. |
Die Anwendung von 'Minus' auf 'Null' wird stets mit Null ausgewertet. | #{-null} | Null wird effektiv in '0' umgewandelt, wenn der Minusoperator angewendet wird. |
Durch das erste Argument wird der Ausdruck kurzgeschlossen. | #{false && someFunc()} | Bedingte EL-Operatoren sind "kurzschließend", was bedeutet, dass der erste Operand genügend Informationen zur Verfügung stellt, um sich des Ergebnisses sicher zu sein, sodass dann der zweite Operand nicht ausgewertet wird. Im Beispiel wird someFunc() nie aufgerufen, da das logische AND von 'false' bei jedem Wert 'falsch' (false) ist. Da dies zur Entwicklungszeit festgestellt werden kann, zeigt dies vermutlich einen nutzlosen oder manuell komprimierbaren Ausdruck an. |
Die Auswertung des zweiten Arguments ergibt stets denselben Wert. | #{myBean.booleanProperty && false} | Dies ist ähnlich dem obigen Problem, nur dass der Ausdruck nicht kurzgeschlossen wird. Im Beispiel ist der Ausdruck immer 'falsch' (false). |
Die Anwendung des Punktoperators ('.') mit Null gibt stets Null zurück. | #{map[null]} | Die Verwendung von Null als Member-Zugriffsobjekt resultiert immer in Null. |
Mögliche Division durch Null | #{x mod 0} | Division und Modulo durch 0 kann in einer Laufzeitausnahmebedingung resultieren. |
Möglicherweise liegt der Index außerhalb des gültigen Bereichs. | #{myBean.stringArrayProperty[-1]} | Bereichsindizes müssen größer oder gleich Null sein und kleiner als die Größe des Bereichs oder der Objektgruppe (wie bei Java). Wenn zur Entwicklungszeit festgestellt werden kann, dass diese Beschränkungen vielleicht nicht eingehalten werden, wird eine Warnung angezeigt. |
Nicht kompatibler Auflistungsvergleich. | #{myBean.coins >= myBean.colors} | Der Vergleich von zwei Auflistungswerten, die nicht denselben Auflistungstyp haben (Java 5 und höher), kann eine Ausnahmebedingung zur Laufzeit verursachen. |
Methodenausdruck erwartet. | <h:commandButton action="#{bean.property}"/> | Wenn das EL-Prüfprogramm Informationen hat, dass ein Tagattribut einen Methodenausdruck erwartet (Methodenbinding vor JSF 1.2), wird es einen Fehler markieren, wenn die Auswertung des EL-Ausdrucks einen Wertausdruck ergibt. Im Beispiel bean.property wird ein Wertausdruck in eine Bean-Eigenschaft für bean aufgelöst. |
Inkompatibilität des Wertausdrucks. | <h:inputText rendered="#{bean.foo}/> | Wenn das EL-Prüfprogramm Informationen hat, dass ein Tagattribut einen bestimmten Werttyp erwartet, wird es einen Fehler markieren, falls der Ausdruck nicht in diesen Typ umgewandelt werden kann. Im Beispiel bean.foo ist eine Bean-Eigenschaft vom Typ 'beans Foo'. Ein beliebiger Klassentyp kann nicht in einen Booleschen Typ umgewandelt werden (ein Boolescher Typ muss übergeben werden). |
Wertausdruck erwartet. | <h:inputText value="#{bean.action}/> | Wenn von einem Tagattribut bekannt ist, dass es einen Wert erwartet, wird ein Fehler markiert, wenn stattdessen ein Methodenausdruck übergeben wird. Im Beispiel erwartet das Wertattribut einen Wertausdruck, aber stattdessen wird ein Methodenausdruck zur Verfügung gestellt (beachten Sie, dass es durch alleinige Betrachtung nicht möglich festzustellen, ob es sich um einen Methodenausdruck handelt). Wir müssen action für bean auswerten, um sicher zu sein. |
Inkompatibilität der Methodenausdruckssignatur. | <h:commandButton action="#{bean.actionTakesArg}" | Wenn die erwartete Signatur eines Methodenausdrucks bekannt ist, wird das Prüfprogramm ihn mit dem zur Verfügung gestellten Ausdruck vergleichen und einen Fehler markieren, wenn keine Übereinstimmung vorhanden ist. In diesem Fall erwartet das Attribut action eine Methode, die keine Argument akzeptiert, aber es wird eine mit Argumenten zur Verfügung gestellt. |
Es wurde erwartet, dass die Eigenschaft lesbar ist, aber sie besitzt keinen Getter. | <h:outputText value="#{bean.writeOnlyProperty}/> | Wenn von einem Tagattribut bekannt ist, dass es eine lesbare Eigenschaft erfordert, aber eine unlesbare zur Verfügung gestellt wird, markiert das Prüfprogramm einen Fehler. |
Es wurde erwartet, dass die Eigenschaft modifizierbar ist, aber sie besitzt keinen Setter. | <h:inputText value="#{bean.readOnlyProperty}/> | Wenn von einem Tagattribut bekannt ist, dass es eine modifizierbare Eigenschaft erfordert, aber eine lesbare zur Verfügung gestellt wird, markiert das Prüfprogramm einen Fehler. |