hallo zusammen, ich steh abermals glaub ein wenig auf dem schlauch. in meinem skript mache ich folgendes:
In der for-Schleife werkel ich dann mit den Bilder o.Ä. dann rum. Machmal kommt dann auch ein Element, wo ein Fehler passiert.
Jetzt meine Frage: ich würde dann für jedes Element das ich gerade bearbeite dessen genaue "Adresse" haben um raus zu finden, wer da ein Problem hat. Als Ergebnis hätte ich gerne etwas in der Art:
root[0].range[4].article[2].image[5]
mit .markupTag.name und .index bekomme ich das noch für das aktuelle Element hin. Nur wie hangel ich dann hoch bis zum Root-Element?
Bin wie immer für alle sachdienlichen Hinweise dankbar!
alert() ist zum Debuggen unpraktisch - man muss dann immer erst den Dialog wegklicken und wenn ESTK mal wieder den Brechpunkt vergisst wird man in einer ungünstigen Schleife mit richtig vielen Dialogen beglückt.
Um direkt im Debugger zu landen, reicht der Aufruf $.bp() - $ ist das vordefinierte Helper-Objekt und bp() steht für Breakpoint. Optional darf man sogar noch eine Bedingung mitgeben.
Danach ganz nett zum Debuggen: app.select(myXMLElement) zeigt das XE direkt in der Struktur an. app.select(myXMLElement.xmlAttributes.everyItem()) klappt sogar noch die Attribute auf.
Beliebige native Objekte (nicht nur XMLElement) lassen sich für später merken, mit der Funktion myObject.toSpecifier(). Das Ergebnis läßt sich mit resolve wieder zum ursprünglichen Objekt umwandeln, soweit dieses noch existiert.
Alert innerhalb des Programmablaufes ist natürlich nicht sinnvoll, ein Alert innerhalb des Catches halte ich für sinnvoll, denn es sorgt dafür, dass erkannte Fehler gemeldet werden, denn ein nicht bemerkter Fehler kann die Programmlogik beeinflussen, man sucht dann vielleicht lange an der falschen Stelle.
Dann kann man entscheiden, wie der Fehler zu behandeln ist: Fehler ignorieren, weil er nicht kritisch ist, Fehler protokollieren, und nach Programmablauf analysieren und ggf. die Fehlerbehandlung anpassen, Kritischer Fehler, Abbruch oder neuen Fehler werfen, je nach Situation.
Ich bin noch immer gegen Alerts mitten im Code. Mein Code wird aber auch massiv auf InDesign Servern eingesetzt, da verbietet sich das von selbst.
Bei der Entwicklung sollte man grundsätzlich die Option im ESTK ausschalten "Do not break on guarded Exceptions" - letzter Eintrag im Debug Menü. Damit findet man Programmfehler sofort - der Debugger steht dann auf der richtigen Stelle.
Ich verwende try-catch nie zur Behandlung von vorher erkennbaren Ausnahmezuständen. Gerade solche Fehler sollte man im Ablauf vorab berücksichtigen, also in unserem Fall etwa fehlende XML Elemente, diese lassen sich mit "isValid" überprüfen. Genauso die Probleme mit Übersatz "overset". Bisher habe ich fast immer einen passenden Test gefunden - Ausnahmen wären defekte Dateien beim Öffnen von Dokumenten bzw. XML Import. Du beschreibst das übliche Vorgehen ja auch mit den anstehenden Programmierer-Entscheidungen.
Das prophylaktische try-catch für unerwartete Ausnahmen in größeren Subsystemen kippt man in ein allgemeines Fehlerreporting - etwa eine Log-Ausgabe. Bei uns produzieren solche Fehler grundsätzlich ein email an die zuständigen Entwickler und einen Fehler-Status. Danach kann sich das Programm entweder (halbwegs) erholen und mit dem nächsten unabhängigen Arbeitsschritt sinnvoll weitermachen, oder es gibt auf mit einem weiteren throw.
Nur auf oberster Aufrufebene bei interaktiven Programmen - also zum Beispiel beim Menü-Invoke oder Button-Klick, würde ich ein try-catch mit Alert oder ähnlichem vorsehen. Beim Server würde entsprechend eine Nachbearbeitung angefordert - mit Fehlerstatus im Asset Management System oder ähnlichem.
Klar, im unbeaufsichtigen Ablauf ist das selbstverständlich. Ausnahme vielleicht ein Fehler, der den weiteren Ablauf unmöglich macht. Auf dem Server sollte so etwas dann eine Meldung (email) an den Administrator auslösen.
Deshalb protokolliere ich im Regelfall Fehler.
Aber das erwähnst Du ja auch weiter unten.
Auch da stimme ich Dir zu. Da man aber vielleicht nicht alle Ausnahmeursachen im Voraus weiß, try - catch mit Fehlerbehandlung. Das hier (und auch in einigen Adobe-Unterlagen) auftauchende try{...}catch(e){}; ist m. E. eine unverzeihliche Unsitte.
Wenn ich das richtig sehe, sind wir über die richtige Vorgehensweise ja weitgehend einig.