Nur für Programmierer(innen) interessant
Dieser Beitrag hätte den für das Buch gesetzten Rahmen überschritten, daher wurde er nicht in das Manuskript übernommen. Er richtet sich an alle, die komplexere Programmieraufgaben unter OS X erledigen möchten / müssen.
Wenn man unter OS X programmiert, egal ob mit AppleScript oder in einer anderen Programmiersprache, dann kann es passieren, dass das Programm einen aufgetretenen Fehler mehr oder weniger deutlich kommuniziert. Solange die Fehlermeldung im Klartext ausgegeben wird, kann man meist etwas damit anfangen. Sinngemässe Beispiele wären “Kann Zielrechner nicht finden”, “Keine Berechtigung die Aktion auszuführen”, oder auch “Häh?????” (wie gesagt, ich habe die Fehlermeldungen nur sinngemäss wiedergegeben). Der letzte Fehler tritt, im Falle von AppleScript, besonders gerne dann auf, wenn man versucht eine Anweisung die für ein Objekt gedacht ist, auf eine Liste dieser Objekte auszuführen – aber das ist Material für einen anderen Beitrag.
Was kann man aber nun machen, wenn man mit einer aussagekräftigen Fehlermeldung wie “Fehler -15284 aufgetreten” konfrontiert wird? Wie in Mehr machen mit dem Mac erwähnt, sollte man sich immer die Developer-Tools von Apple auf Rechnern installieren, auf denen man zu programmieren gedenkt Selbst wenn man glaubt die Entwicklungswerkzeuge nicht zu benötigen. Das Installationspaket enthält auch die so genannten Header-Files für die Entwicklung in Objective-C und C++.
[Alle die mit der Funktionsweise von Header-Files vertraut sind, sollten nach der Box weiterlesen.]
Was sind Header-Files?
Ohne hier einen Grundkurs in C-Programmierung loszutreten: Ein Header-File enthält (unter vielem anderen) Vereinbarungen die in etwa so aussehen (wiederum nur beispielhaft):
ichBinEinFieserFehler = -4711
Diese Zeile hat (unter anderem) folgenden Sinn, sie stellt eine Verbindung zwischen der Fehlernummer (-4711) und dem Errorcode (ichBinEinFieserFehler) her. Diese Verbindung erlaubt es beim Programmieren in den diversen Dialekten der Programmiersprache “C” den Errorcode statt der Fehlernummer zu benutzen und trotzdem die Fehlernummer zu meinen. Der Programmcode wird dadurch lesbarer. Das würde im Programmcode dann in etwa so aussehen, if(ichBinEinFieserFehler) und ist deutlich lesbarer als if(-4711).
[Trotzdem gelesen? Es ging nur ums Prinzip, ehrlich!]
Wenn man nun einen Fehler auslöst, welcher keine Erklärung im Klartext an das ausführende Programm zurückgibt, dann bekommt man eine Dialogbox mit der (wenig aussagekräftigen) Fehlernummer, und sonst nichts. Hat man Zugriff auf die Header-Files kann man diese nach der Fehlernummer durchsuchen, nur sollte man dies nicht per Hand machen.
Wer wissen möchte, wieviele Header-Files sich allein in befinden, kann dies mit folgendem Befehl tun:
find /System/Library/Frameworks/ -name \*.h | wc -l
Bei mir gab der Befehl 2.675 Dateien zurück, keine verlockende Aussicht all diese Dateien zu durchsuchen, oder? Alle die sich auf der Command-Line wohlfühlen, werden jetzt ahnen worauf ich hinausmöchte: Wenn man den oben gezeigten Befehl ein wenig erweitert, kann man den Rechner für sich suchen lassen.
find /System/Library/Frameworks -name \*.h -print0 | xargs -0 grep -e -15284
gibt als Antwort folgendes aus (der angezeigte Pfad wurde mit Leerzeichen versehen, um ihn darstellen zu können):
/System/Library/Frameworks/Carbon.framework/Versions /A/Frameworks/OpenScripting.framework/Versions/A/ Headers/FinderRegistry.h: errFinderLockedItemsInTrash = -15284, /* there are some locked items in the trash*/
Auf den ersten Blick nicht besonders vielversprechend, auf den zweiten Blick allerdings… /* there are some locked items in the trash*/ ist eigentlich schon die Erklärung. Der Finder konnte den “Papierkorb” nicht entleeren, weil sich gesperrte Objekte darin befinden. Falls die gefundene Zeile keinen Kommentar enthalten sollte (der Satz zwischen /* und */) dann würde auch errFinderLockedItemsInTrash etwas mehr Licht in die Sache bringen.
Wer auf dem Mac programmiert, profitiert also von den installierten Developer-Tools. Nun zur schlechten Nachricht: Die gezeigte Vorgehensweise funktioniert nicht in allen Fällen, soll heissen, es existieren durchaus Fehlerkonditionen die man auch auf diese Weise nicht vollständig enträtseln kann. Einen Versuch ist es trotzdem wert.
Sehr guter Beitrag! Habe dann auch gleich noch »alias errorcode=’find /System/Library/Frameworks -name \*.h -print0 | xargs -0 grep -e ‘« in meine »~/.bash_profile« aufgenommen. So geht das ganze mit »errorcode -12345« noch viel leichter von der Hand.
@DASKAjA: Gute Hinweis. Man sollte dann nur im Kopf behalten wo der Alias nach den Errorcodes sucht. Es gäbe ja potentiell noch ein paar andere Möglichkeiten; die braucht man aber nur in ganz speziellen Fällen.