In einer bestehende Webanwendung wollte ich die JQuery-Bibliothek von Version 1.4.X auf 1.6.x aktualisieren. Zum größten Teil gab es keine Probleme, nur an folgender Stelle funktionierte es nicht.

In der Webseite gibt es eine Textbox und ein Drop-Down-Menü zur Schnellauswahl häufig benutzter Begriffe. Wenn man aus dem Menü etwas auswählt, soll der gewählte Begriff in die Textbox geschrieben werden. Dazu nutze ich die folgenden Funktionen:

function put_selected_in_textbox(selectbox, textbox){
  var sel = selectbox.attr('selectedIndex')
  if (sel >= 0){
    var txt = selectbox.find('option:selected').text();
    textbox.val(txt);
  }
  else {
    textbox.val("???");
  }
}
function connect_select_to_text(selectbox, textbox)
{
  selectbox.bind('change', function(){
    put_selected_in_textbox(jQuery(this), textbox);
  });
}
jQuery(document).ready(function(){
    connect_select_to_text( jQuery('#id_of_select'), jQuery('#id_of_textinput'));
});

Mit jQuery-1.6 funktioniert das plötzlich nicht mehr. Der Debugger brachte ans Licht, das die Methode selectbox.attr(‘selectedIndex’) jetzt “undefined” liefert. Nach einigen Suchen fand ich den Grund:

jQuery unterscheidet jetzt genauer zwischen Properties und Attrubuten. In der Dokumentation zu der Methode prop() findet man darüber auch eine Begründung.

Meine Übersetzung:

Auf die Properties selectedIndex, tagName, nodeName, nodeType, ownerDocument, defaultChecked, und defaultSelected greift man mit der prop() Methode zu. Vor jQuery 1.6 war es möglich, auf diese Properties mit attr() zugreifen, dies liegt jedoch nicht im Verantwortungsbereich der attr() Methode. Denn diese Properties haben keine dazugehörigen Attribute und sind deshalb nur Properties.

Da fragt man sich schon was denn jetzt eigentlich der Unterschied zwischen Attributen und Properties ist.

 Im Java-Beans-Programmiermodell werden die Eigenschaften jeweils Properties genannt, man greift auf sie mit getX() und setX() zu. In Ruby on Rails hingegen heißen die Felder eines ActiveRecords “attributs”. Im “normalen” Englisch bezeichnet man mit Properties etwas ist, was man besitzt, z.B. Grundstücke oder Häuser(real property), aber auch die “intellectual property”. Das hilft uns aber irgendwie nur wenig weiter.

Offenbar beziehen sich bei jQuery die Attribute auf die in HTML/XML-Tags definierbaren Attribute. Also sind z.B. href und title Attribute des a-tags. Die definierten Attribute des select-Tags findet man in der HMTL 4.01 W3C-Spezifikation.

Alles, was so nicht definierbar ist, ist demnach kein Attribut.

Ende gut, alles gut?

Doch gerade, als es anfing Sinn zu ergeben, bin in der DOM-Spezifikation, die den Zugriff auf HTML-Elemente von Javascript regelt, auf folgenden Satz gestoßen:

1.6.1. Property Attributes

HTML attributes are exposed as properties on the element object.

Als Entwickler bleibt der unbefriedigende Zustand, das die Begriffe Properties und Attribute je nach Kontext etwas anderes bedeuten, und manchmal sogar in verschiedenen Versionen derselben Bibliothek verschieden definiert sind

Alle drei Methoden liefern das gleiche Ergebnis. Was nehmen wir wann? Warum ist es überhaupt wichtig? Nimmt man die falsche Methode, dann erzeugt unsere Ruby-on-Rails-Anwendung überflüssige Datenbankabfragen oder braucht mehr Speicher als eigentlich nötig. Die Anwendung skaliert dann schlechter. Um mir die Unterschiede zwischen den Methoden leichter zu merken habe ich folgendes Schema erstellt.

count: das lese ich als Befehl.
Der Befehl wird an die Datenbank weitergegeben, die Datenbank führt dann eine SQL-Anfrage “select count(*) from …” aus.

Diese Methode ist perfekt wenn wir wirklich nur die Anzahl wissen wollen: Es werden keine überflüssigen Daten von der Datenbank zur Anwendung geschickt, sondern nur die Anzahl zurückgegeben. Die Datenbank ist bei dieser Art von Anfragen meist auch schneller, weil sie die Anfrage nur aus ihren Index beantworten kann.

Wenn die Daten aber schon in unserer Anwendung verfügbar sind, wird trotzdem ein Datenbankaufruf abgesetzt.

length: eine physikalische Eigenschaft.

Die length()-Methode liefert die Länge des Arrays (bzw, der Assoziation oder der Relation).

Wenn die Daten schon im Speicher sind, wird die Datenbank nicht gefragt. Wir haben dann eine Datenbankanfrage gespart.

Beispiel: wir zeigen in der View eine Tabelle mit unseren Daten, und darunter die Anzahl der Elemente. Die Daten mussten wir sowieso schon aus der Datenbank laden, deshalb wäre es Unsinn die Datenbank nochmal nach der Anzahl zu fragen.

Wenn die Daten noch nicht in unseren Speicher sind, schlägt die Magie von ActiveRecord zu. Das Array wird befüllt (populated). Dazu wird die Datenbank nach allen Werten der betreffenden Objekte gefragt. Die Objekte werden komplett aufgebaut, mit allen Attributen, um dann durchgezählt zu werden.

Wenn wir nur die Anzahl wissen wollen ist das natürlich unnötig. Dann ist count() besser.

Wenn wir die Daten aber sowieso gleich brauchen ist das genau richtig.

size: die abstraktere Version von length.

Wenn Daten schon da sind, ruft die size() Methode intern length() auf. Wenn die Daten noch nicht da sind, ruft size() intern stattdessen die count()-Methode auf. Das klingt wie die perfekte Mischung.

In einem Fall ist size() Methode trotzdem eine schlechte Wahl: Wenn wir die Daten kurz danach doch noch brauchen, haben wir einen überflüssigen “select count”-Datenbankaufruf erzeugt.

]]> http://meier-online.com/2012/03/rails-activerecord-count-length-size/feed/ 0 http://meier-online.com/2011/10/lwuit-1-5/ http://meier-online.com/2011/10/lwuit-1-5/#comments Sun, 09 Oct 2011 13:21:06 +0000 meier http://meier-online.com/?p=794 Sun hat mit „Java Mobile Edition“ (JME) die Softwareplattform geschaffen, die weltweit auf Milliarden von Handys funktioniert. Die Plattform ist inzwischen in die Jahre gekommen, und besonders für die Gestaltung der Benutzerschnittstelle bietet Sie nur wenig, um die Möglichkeiten heutiger Handys auszunutzen.

Mit LWUIT  wurde ebenfalls von Sun eine Bibliothek für die Gestaltung von Benutzerschnittstellen vorgestellt. LWUIT unterstützt Touchscreens und Animationen. Ein Jahr lang konnte man zwar in dem Blog eines LWUIT-Entwicklers die Weiterentwicklung verfolgen, es gab jedoch keine neuen Versionen. Ich habe schon befürchtet, dass der neue Eigentümer Oracle das Projekt ganz einschlafen lässt. Das der genannte Blog bei Google liegt und nicht bei Sun bzw. Oracle wertete ich ebenfalls als Indiz, dass das Projekt für die Firma nicht besonders wichtig zu sein scheint.

Anfang August 2011 ist schließlich doch noch die Version 1.5 veröffentlicht wurden.

Erfahrungen beim Upgrade.

Die Größe eine Handyprogramms ist immer noch ein Thema. Preiswerte oder ältere Handy haben oft Grenzen für die Größe eines Javaprogramms. Auch die Datenübertragung ist für viele Nutzer weiterhin noch nicht kostenlos.

Die Bibliothek war für eine JME-Bibliothek schon in Version 1.4 sehr groß, und der Umfang die Bibliothek ist nochmal gestiegen. Zum Glück entfernt der Obfuscator die unbenutzten Bibliotheksbestandteile recht effektiv. Für zwei verschiedene Programme komme ich mit allen Resourcen auf folgende Werte nach dem Umstieg von 1.4 auf 1.5:

Programm A: 212kb -> 245kb

Programm B: 417kb -> 456kb

Die Entwicklungsversion der Anwendung B mit Debuging-Informationen und ohne Obfuscator war über ein 1MB und ließ sich in der Standardeinstellung des JME-SDK nicht starten. Man kann die erlaubte Größe aber durch ändern einer Konfigurationseinstellung anpassen:

Datei: jwc_properties.ini
system.jam_space = 1000000

Die beiden Anwendungen ließen sich leicht upgraden. Kritisch war in der IDE Netbeans nur, wirklich alle Referenzen auf LWUIT 1.4 aus dem Projekt zu entfernen, auch in den eigenen Bibliotheken.

Es gab einige „Deprecation Warnings“, die leicht zu beheben waren. Der Resourceeditor hat in 1.5 sehr große Änderungen erfahren. Geändert wurde der Umgang mit den „selected“ und „pressed“ Zuständen. Hier musste man die Anwendungen im Detail überprüfen und teilweise nachbessern. Insgesamt ging die Umstellung aber problemloser als befürchtet.

Mehrzeilige Elemente

Aus meiner Sicht unvollständig ist immer noch die Unterstützung von mehrzeiligen Elementen. Ein Label ist zunächst mal nur einzeilig, ebenso wie ein Button, oder eine Checkbox.

Von den einfachen UI-Elementen kann einzig das TextArea-Eingabefeld mit mehrzeiligen Text umgehen. Immerhin lässt sich das ausnutzen:

Für ein einfaches mehrzeiliges Label kann man ein Eingabefeld verwenden, es auf nicht editierbar setzen und die UIID manipulieren, so dass die Stilinformationen eines normalen Labels genutzt werden:

TextArea descLabel = new TextArea(descriptionText);
descLabel.setEditable(false);
descLabel.setUIID("Label");

Ilias ist ein sogenanntes Lernmanagementsystem (LMS), d.h. ein System für webbasierte Bildungsangebote. Es ist ein sehr umfassendes System, das neben den Inhalten in Onlinekursen auch Kommunikationsmöglichkeiten wie Foren, Mail und Chat integriert.

Beim Einsatz eines solchen Systems eines solchen Systems im Kontext einer bestehenden Organisation tritt meistens der Wunsch auf, die Gestaltung der Benutzeroberfläche zu verändern.

Gründe hierfür sind beispielsweise:

1. Differenzierung: Man möchte sein Angebot nicht wie jedes andere aussehen lassen.
2. Man möchte es an das eigene Coperate Design anpassen, dazu gehört das Unternehmenslogo und die Farbgestaltung
3. Konkrete Bedürfnisse der Anwender: In unserem Projekt wollen wir die Bedienung vereinfachen, in dem wir selten benutzte Optionen weglassen.
4. Vorschriften, die einzuhalten sind. Das können vorgeschriebene Benennungen sein, oder Ergonomierichtlinien für die Schriftgröße

Wie Ilias Webseiten generiert

Eine von Ilias erzeugte Seite enthält wie andere Webseiten auch CSS-Stilvorlagen und Bilder. Zu den Bilder gehören Icons sowie Hintergründe, beispielsweise um Rahmen mit abgerundeten Ecken zu erzeugen.

Weder die Bilder noch die Stilvorlagen werden direkt von Ilias beeinflusst, sondern werden vom Webserver ohne Veränderung aus dem Dateisystem ausgeliefert. Der Ilias Kern selbst erzeugt die HTML-Struktur, und verwendet dafür Inhalte aus der Datenbank sowie Textfragmente aus sprachabhängigen Textdateien und baut sie mit Hilfe von Templatedateien zusammen.

Wollen wir die Erzeugung der Webseiten jetzt anpassen, können wir den Quelltext von Ilias selbst verändern. Bei einer neuen Version von Ilias hätten wir dann aber das Problem, die eigenen Änderungen mit den offiziellen Änderungen zusammenzuführen. Zum Glück gibt es eine Alternative:

Ilias bietet einen Mechanismus, die Erzeugung der Webseiten mit sogenannten Skins zu verändern, ohne dafür die Quelltexte von Ilias selbst verändern zu müssen.

Darüber hinaus können verschiedene Skins für verschiedene Nutzer freigeschaltet werden, oder man kann den Nutzern die Auswahl des Skins überlassen. (Siehe Beschreibung der Skin Einstellungen)

Was ist ein Ilias-Skin?

Formal betrachtet ist besteht ein Ilias-Skin aus einem Verzeichnis. Es enthält eine Konfigurationsdatei sowie eine Menge von anderen Dateien. Diese Dateien werden von Ilias anstelle der eigenen genutzt, überschreiben sozusagen die Originaldateien.

Ein Skin beeinflusst zunächst mal natürlich die Darstellung. Dies geschieht durch eigene Versionen von CSS-Stilvorlagen und von Bildern.

Zum Teil kann sogar die Funktionalität mit einem Skin verändert werden. Es lassen sich nämlich die zur HTML-Generierung genutzten Templates im eigenen Skin überschreiben.

Trotzdem hat man als Autor eines Skins nicht immer die volle Kontrolle. Teile des HTML-Codes werden von den Ilias-Kernsystem selbst erzeugt und lassen sich nur durch Änderung am Quelltext verändern. Das betrifft insbesondere die Struktur von Eingabeformularen.

Auch die Texte wie beispielsweise die Beschriftungen von Buttons gehören nicht zum Skin. Die können statt dessen mit einer eigenen Sprachdatei unabhängig vom Skin verändert werden.

Details, wie man eigene Skins erstellt, lesen Sie demnächst in zweiten Teil dieser Artikelserie.

Selbst bei so etwas einfachen wie der Addition von Zahlen gibt es manchmal Überraschungen. Doch der Reihe nach. Wenn wir den interaktiven Ruby-Interpreter “irb” starten, können wir in als einfachen Rechner nutzen.

irb> 1+2
=> 3

So weit so praktisch. In der Programmierpraxis liegen Zahlen häufig als String vor, z.B in Textdateien oder als Formularparameter in Webseiten. Probieren wir also folgendes:

> input="1"
> input+2
TypeError: can't convert Fixnum into String

Richtig, wir müssen in Ruby erst explizit den String in einen Integer umwandeln. Dafür gibt es die Methode to_i

> input.to_i+2
=> 3

Ok, damit es etwas besser aussieht, fügen wir ein Leerzeichen ein

> input.to_i +2
=> 1

Huch? Was war das? Ist unsere Variable vielleicht überschrieben worden? Probieren wir es mal direkt:

>"1".to_i+2
=> 3

>"1".to_i +2
=> 1

Bei einen Leerzeichen vor dem Pluszeichen und keinem Leerzeichen nach dem Pluszeichen gibt es ein anderes Ergebnis. Wo kann dieses Ergebnis herkommen? Probieren wir andere Zahlen:

>"2".to_i +2
=> 0

Es wird immer rätselhafter!

> "1".to_i +1
ArgumentError: illegal radix 1

Aha, es gibt eine Spur. Vielleicht schaut wir uns die Dokumentation der Methode “to_i”genauer an:

http://ruby-doc.org/core/classes/String.html#M000787

Die Methode to_i hat demnach einen optionalen Parameter Namens “radix”. Der String kann als Zahl im Hexadecimal-, Decimal, Octal- oder Binärsystem interpretiert werden.

Weiter steht dort momentan: “This method *never* raises an exception.” Also soll die Methode, falls sie auf Grund von unerlaubten Eingaben zu Fehlern führt, immer 0 liefern, und niemals eine Exception erzeugen. Gut, wenn das so exakt dokumentiert ist. Leider ist die Aussage so nicht richtig, denn der ArgumentError ist schließlich auch eine Exception.

Wie hilft uns dies jetzt, das eigenartige Verhalten zu erklären? In Ruby kann man die Klammern auch bei einen Funktionsaufruf weglassen. Offenbar macht unser Rubyinterpreter aus:

"1".to_i +2

"1".to_i( +2 ) => "1".to_i( 2 ) => 1

Der String “1″ wird als Binärzahl interpretiert, und liefert dann die Zahl 1. Eine Addition findet nicht mehr statt. So lässt sich auch erklären:

"2".to_i(+2) = 0

Ruby versucht den String “2″ als Binärzahl zu interpretieren. Das geht nicht, weil Binärzahlen nur aus 0 und 1 bestehen. Ruby liefert dann wie dokumentiert einfach eine 0 zurück.

Insgesamt bleibt dabei ein ungutes Gefühl: Selbst bei einer einfachen Addition kann durch hinzufügen oder weglassen von Leerzeichen aus einen korrekten Programm ein Falsches werden. Leider der Preis, den man in Ruby für den Verzicht auf Klammern zahlen muss. In diesen Fall ermöglicht der optionale Parameter der Methode “to_i” diese Mehrdeutigkeiten. Optionale Klammern in Zusammenspiel mit optionalen Parametern sind leider eine gefährliche Kombination.

Texte gehören zu den Teilen einer Anwendung, die häufig geändert werden. Wenn dann noch externe Übersetzer im Spiel sind, kann es leicht zu fehlenden Übersetzungen kommen

Wir möchten deshalb automatisch testen, dass es zu allen Texten in Sprache A auch Übersetzungen in Sprache B vorhanden sind. Ein solcher Test allein hilft schon sehr, und sollte ja nicht so schwierig sein.

Leider gibt es dabei eine Überraschung: in der Internationalisierung-API findet sich zur Zeit (Rails 2.3.5) keine Möglichkeit, alle Schlüssel aufzuzählen (sprich iterieren). Man muss also offenbar die Yaml-Dateien selbst einlesen, um an die Menge aller definierten Schlüssel zu kommen. Unserer Test wird dabei leider abhängig von der konkreten Art der Datenhaltung.

texts_hash = YAML::load(IO.read('config/locales/de.yml'))

Wie haben nun einen rekursiven Hash. Um alle Schlüssel zu überprüfen, extrahieren wie sie mit einer gesonderten Funktion. Diese Funktion ist einfach rekursiv aufgebaut.

def deep_hash_key(hash, prefix)
  hash.keys.sort.collect{|key2|
    val = hash[key2]
    newprefix = prefix.nil? ? key2 : "#{prefix}.#{key2}"
    if val.is_a? Hash
     deep_hash_key(val, newprefix)
    else
      newprefix
    end
  }
end

Wollen wir jetzt die Übersetzungen für alle Schlüssel prüfen lauert die Zweite Falle: Wenn die Übersetzung eine Variableninterpolation enthält, erhalten wir einen Fehler beim Aufrufen der translate() Methode ohne den passenden Hash. Offenbar liefert uns die API auch keinen Zugriff auf den String ohne Interpolierung. Da uns in diesen Test nur die Existenz einer Übersetzung interessiert, und nicht ihr konkreter Wert, fangen wir die Exception “MissingInterpolationArgument” einfach auf.

Für eine deutsche Anwendung mit Übersetzungen in Englisch und Französisch sieht dann der Test so aus:

def test_all_texts_should_exists
  texts_hash = YAML::load(IO.read('config/locales/de.yml'))
  de_keys = deep_hash_key(texts_hash['de'], nil).flatten
  for lang in ['de', 'fr', 'en']
    I18n::locale = lang
    for key in de_keys
      begin
        val = I18n.translate(key, :default => nil, :raise => true)
      rescue I18n::MissingTranslationData
        val = nil
      rescue I18n::MissingInterpolationArgument
        val = true  # there was a value, only an argument is missing
      end
      assert_not_nil(val, "key missing for locale #{lang}: #{key}")
    end
  end
end

Wenn jetzt eine Übersetzung fehlt, liefert der Test eine Fehlermeldung der Art:

test_all_texts_should_exists(LocalisationTest): key missing for locale en: users.edit.title

Die fehlende Übersetzung können wir dann ergänzen, bevor wir eine neue Version der Anwendung veröffentlichen.

Selbstidentifizierende Fehler

Es gibt in ANSI-C einen Mechanismus, viele Fehler auch ohne Debugger aufzuspüren: Das Assert Macro. Ein Teil des Problems liegt in Deutschland wohl auch im Namen: Assert ist ein Wort, welches im allgemeinen im Englisch an der Schule nicht benutzt wird.

Meine Übersetzung hierfür lautet Zusicherung. Das Assert Macro prüft diese Zusicherung, und druckt, falls es schief geht, seine eigene Datei mit Zeilennummer im Quelltext aus. Ein Beispiel:

int readFile(
    char * filename
    char * buffer
)
{
    int filehandle;
    assert( filename != NULL);
    assert(strlen(filename) > 0);
    assert(strlen(filename) < MAX_FILENAMELEN);
 
    filehandle = open(filename, READ_ONLY);
    ...
}

Falls jetzt irgend jemand meine Funktion mit falschen Parametern aufruft, z.B. mit einem leeren String, passiert während des Programlaufes folgendes:

assertion failed in file readfile.c, line 34:
strlen(filename) > 0
program aborted

Der Tester, wer immer das ist, kann in der angegebenen Datei die Zeile aufspüren, in der der Fehler auftrat, und erfährt dann, dass die Funktion readFile mit einem Leerstring aufgerufen wurde. Oft hat man damit schon die Fehler gefunden, in den anderen Fällen hat man zumindestens einen Anhaltspunkt.

Frage: Sollte man nicht eine wasserdichte Fehlerbehandlung machen?

Welcome to Reality! Die obige Lösung ist ein Einzeiler. In der Praxis bedeutet dieses: Ein assert() schreibt man auch hin, wenn man meint, das ein bestimmter Fall in der Praxis nie und nimmer auftreten wird. Im obigen Beispiel ist der Programmierer der Aufruffunktion dazu verflichtet, der Funktion einen Buffer zur Verfügung zu stellen. Wenn der Buffer bei NULL liegt, hat er Mist gemacht. Bei der Länge des Filenames kommt es auf die Anwendung an: Falls hier ein vom Endbenutzer eingegebener String direkt benutzt wird, ist die assert Lösung allenfalls während der Prototypphase erlaubt.

Die Fehler, von denen man damit rechnet, dass sie während des normalen Betriebes auftreten, sollte man selbstverständlich auch korrekt abfangen.

Das Assert hat auch seinen Sinn, wenn es nicht feuert: Bei einer Fehlersuche kann ich sicher sein, dass ein bestimmtes Problem nicht aufgetreten ist, dass ich den Fehler also woanders suchen muss.

Nicht zuletzt teile ich den armen Leuten, die mein Programm einmal warten müssen, etwas über meine Intention mit: Der Pointer darf kein NULL-Pointer sein, der Dateiname soll weniger als X Buchstaben haben, … Das alles kann man auch in die Kommentare schreiben, aber nur Code lügt nicht.

Frage: In C++ und Java gibt es doch den Exception Mechanismus.

Ja der ist oft noch besser, aber leider auch noch etwas komplizierter. Vieles, was ich gesagt habe, läßt sich auch auf diesen Mechanismus übertragen. Leider kann man sich auch nicht immer aussuchen, in welcher Sprache man programmiert.

Frage: Wenn diese Fehlermeldung dann im laufenden Betrieb beim Kunden auftritt, ist das doch eher peinlich. Und das Programm wird doch bestimmt größer und langsamer? Das heisst doch, nacher muß ich alle asserts() wieder rausnehmen?

Zum Glück nicht! Das Assert läßt sich durch einen Compilerschalter aktivieren oder deaktivieren. Wenn in irgendeiner Headerdatei steht:

#define NDEBUG

oder in der Makedatei:

-DNDEBUG

so wird für das Assert kein Code erzeugt, so als ob man alle assert Zeilen rausediert hätte.

Frage: Wie funktioniert das eigentlich?

Das Geheimnis liegt im Zusammenspiel von Preprocessor und Compiler. Das Assert ist als Macro implementiert, im allgemeinen in der Datei assert.h. Das Grundgerüst ist folgendes:

#ifdef NDEBUG
#define assert(exp)
#else
#define assert(exp) \
 ( (exp) ? (void) 0 : _assert(#exp, __FILE__, __LINE__))
#endif

Das sieht doch reichlich kryptisch aus, ist jedoch gar nicht so kompliziert: Macros sind Textersetzer. Mittels #ifdef…#else…#endif wird dafür gesorgt, das nur Code erzeugt wird, falls das Symbol NDEBUG nicht definiert ist. Dann wird nämlich assert zusammen mit seinen Argument durch einen leeren String ersetzt, der Compiler bekommt die betreffenden Zeilen nicht einmal zu Gesicht. Im Debugfall setzt der Compiler die Wörter __FILE__ und __LINE__ durch die aktuelle Quelldatei (nicht iassert.h, sondern die Datei der Aufrufstelle) und die aktuelle Zeilennummer. Der Ausdruck #exp wird durch den aktuellen Ausdruck als String ersetzt.

Die eigenartige Klammerstruktur (xxx ? yyy : zzz) gehört zum normalen C Sprachumfang, wird jedoch von wohlerzogenen Programmierern nur in Ausnahmefällen wie diesen verwendet. Es ist etwas wie ein verkürztes if-statement. Die Backslashes am Ende der Zeile verlängern die Zeilen, da der Macromechanismus ausschließlich zeilenorientiert arbeitet. Insgesamt erzeugt der Preprozessor aus der Zeile

assert(strlen(filename) < 0);

die Zeile

((strlen(filename) > 0) ? (void) 0 : _assert("strlen(filename > 0", __FILE__, __LINE__));

Die tief im Inneren einer Library definierte Funktion _assert() gibt die Argumente, z.B. mit printf(), auf den Bildschirm aus und bricht das Programm ab.

Frage: Alles schön und gut, aber ich programmiere mit einem Fenstersystem, manchmal programmiere ich auch Anwendungen ganz ohne Bildschirm. Was nun?

Viele Benutzer haben Glück: In einigen Entwicklungsumgebungen gibt es ein assert(), das ein Pop-up-Fenster öffnet. Ansonsten lohnt es sich für solche Fälle, ein assert-Macro selbst zu schreiben. Das prinzipielle Vorgehen ist dabei, eine Ausgabefunktion zu schreiben, die die betreffende Ausgabe irgendwohin ausgibt, die Datei assert.h zu kopieren und statt des _assert die eigene Ausgabefunktion aufzurufen. Die Ausgabe kann in eine Logdatei, über die Soundschnittstelle, als Email, als Fax, oder als was auch immer erfolgen.

Ähnlich ist auch in anderen Programmiersprachen zu verfahren. Meistens bieten die Hersteller irgendeine Entsprechung zu __FILE__ und __LINE__ an, selbst wenn es nicht im offiziellen Sprachstandard ist.

Frage: Das ist ja toll, was man mit Macros alles machen kann, ich habe da gerade eine Idee …

Vorsicht: Wer Macros einsetzt, nur um ein paar Zeilen Code zu sparen, wird es irgendwann bitter bereuen.

Ich habe mal bei einer Firma ein Macro entdeckt, das dazu dienen sollte, Teile eines Records in einen anderen zu kopieren. Dieses Macro war schon mehrere Jahre bei dieser Firma im Einsatz, leider war es nur manchmal korrekt. Ich habe mit mehreren anderen Entwicklern lange vor dem Macro gesessen, um herausfinden, was es eigentlich tat. Es arbeitete ganz gut. Je nach dem, mit welchem Record man es aufrief, überschrieb es jedoch einen verbotenen Speicherbereich. Das Macro war bestimmt für etliche Abstürze verantwortlich, auch bei ausgelieferten Systemen. Die Firma war übrigens kurze Zeit später pleite …

Zurück ins Jahr 2009

Im Jahr 2009 werden Assert-Methoden oft in Unit-Tests verwendet. Dagegen ist auch nichts einzuwenden. Beim vorliegenden Text ging es mir aber um etwas anderes: die Verwendung von Assert im Programmtext selber. Diese Asserts können auch bei unerwarteten Fehler helfen. Sie sind auch allgemeiner: Sie prüfen Aussagen über das Programm, die immer gelten sollen, nicht nur bei bestimmten Testdaten. Asserts im Programmtext selbst sind deshalb auch bei Nutzung von Unittests nützlich.