Domino 9 und frühere Versionen > Entwicklung

Export von Feldern in ein .txt File

<< < (3/4) > >>

flaite:

--- Zitat von: koehlerbv am 10.11.05 - 17:30:16 ---Wegen des String-Concatenators hat gerade heute Axel J. sehr gute Beispiele aufgemalt, warum es "&" wie offiziell gefordert statt "+" heissen muss:
100 + "200" = 300

--- Ende Zitat ---

Die guten Beispiele hab ich btw. aus der Notes Hilfe.  ;D
Gerade auch für die Anfänger ist es eine gute Idee, da manchmal ein bischen rumzuklicken und zu lesen.
Es ist ca. 2 mal lebendiger geschrieben als die Java Language Specification und 2.570 mal lebendiger als die EJB2.0 Specification.  :-[

Gruß Axel 

Axel:

--- Zitat von: koehlerbv am 10.11.05 - 17:13:22 ---Ich würde hier dringend noch eine Ergänzung empfehlen (kein Object ohne Prüfung):

--- Ende Zitat ---

Hast ja recht. Ich habe aber gerade das Bsp. aus der Hilfe kopiert, angepasst und mit ein paar Kommentaren versehen.   ::)



--- Zitat von: koehlerbv am 10.11.05 - 17:13:22 ---Noch eine Erläuterung: Axel hat rtitem als Variant deklariert und nicht als NotesRichTextItem, da wir ja nicht wissen können (NIEMALS), ob das Item "Body" wirklich vorhanden ist bzw. vom Type RICHTEXT ist.

--- Ende Zitat ---

Das habe ich eigentlich so aus der Hilfe übernommen. Normalerweise nehme ich hier immer NotesRichTextItem und habe noch keine Probleme gehabt. Natürlich immer mit der Objekt-Prüfung. Desöfteren habe ich aber auch schon den Typ Variant gesehen.

Kannst du mir mal kurz erklären wo hier die Unterschiede liegen und welchen Typ man am besten nehmen soll. Für mich ist es interessant mal Meinungen von anderen zu hören. Man lernt ja nie aus.

Axel

koehlerbv:
Axel, das sollte keine Kritik sein, wirklich nicht. ich habe nur noch ergänzt, und zu diesem Thema könnte man noch sehr, sehr viel schreiben. Aber der "Hammer" kann sich ja auch erstmal selber Gedanken machen.

Zu Deiner Frage meine Meinung (und nicht die enzyklopädische Antwort): Wenn Du ein Item, welches nicht vom Typ RTI ist, einem Objekt vom Typ RichTextItem zuweist, dann scheppert es. Variant kommt damit klar, aber den Variant (oder DAS Variant ? Oops, da habe ich eine offene Frage) juckt das nicht.

Zusammen mit den Prüfungen ist man damit auf jeden Fall auf der sicheren Seite. Und das zählt. Meiner Meinung nach ist die nackte, von Notes / Domino generierte Fehlermeldung "Object variable not set" mit das peinlichste, was es gibt.

Aber das sind nur meine 2 ct. Andere Meinungen höre ich auch sehr gerne - es geht ja um den Zuwachs an Erfahrungen für uns alle. Und "nobody's perfect".

Bernhard

Axel:
Hi Bernhard,

ich hab's auch nicht als Kritik aufgefasst. Eigentlich ist eine saubere Fehlerbehandlung eine Selbstverständlichkeit, so dass man nicht immer darauf hinweisen müsste. Aber leider wird sie oft genug außer Acht gelassen.

Vielen Dank für deine, wenn auch nicht enzyklopädische  ;D , Antwort. Also machts eigentlich Sinn immer den Typ Variant zu verwenden. Obwohl ich mich erinnern kann, das es mal Probleme gab, als ich Variant benutzt habe. Nach dem ich den Typ auf NotesRichTextItem geändert hatte ging's. Ich weiß leider nicht was das war.

Da ich mich in meinen Anwendungen immer definitiv auf ein RTF-Feld bezogen habe, hat's bei mir auch nie Probleme gegeben.

Axel

koehlerbv:

--- Zitat von: Axel am 10.11.05 - 20:06:51 ---Also machts eigentlich Sinn immer den Typ Variant zu verwenden.
--- Ende Zitat ---

Hallo Axel,

Variant aber nur in diesem Kontext - ansonsten kann das sträflich sein. Hier macht aber Variant wirklich Sinn - der  DataType existiert ja nicht umsonst.

Was folgendes angeht:

--- Zitat von: Axel am 10.11.05 - 20:06:51 ---Da ich mich in meinen Anwendungen immer definitiv auf ein RTF-Feld bezogen habe, hat's bei mir auch nie Probleme gegeben.
--- Ende Zitat ---

Da kann man ja nur sicher sein, wenn man das RTI gerade erst selber angelegt hat (vorher muss man natürlich prüfen, obn man überhaupt etwas anlegen kann). Sonst kann man ja damit konfrontiert werden, dass sich - aus den verschiedensten Ursachen - ein Item einfach vom Acker macht: Dokument auf anderem (unsauberen / unerwartetem) Wege erzeugt, Dokument im Eimer etc. pp.

Mein prägendes Ereignis war wohl , als wir vor etlichen Jahren zu unserem Lieblingsplätzchen am Sallingsund in den wohlverdienten Sommerurlaub fahren wollten. Am Vorabend musste unbedingt noch eine eigentlich für den folgenden Monat geplante Applikation in Betrieb genommen werden (trotz meines Protests). Murphies Law verlangte, dass das schief geht: Eines von ca. 100.000 Dokumenten sah nicht so aus wie erwartet (ein Item war nicht existent - in genau einem Dokument. Warum auch immer - ich weiss es nicht mehr). Es war eine kurze Nacht nach der Lösung des Problems, und am nächsten Tag dann 1.300 Kilometer zu fahren. Meine Frau hat sich dann zu recht beklagt, dass sie viel mehr als die vereinbarten Strecken am Steuer sitzen musste. Die zusätzlich eingebauten Prüfungen haben uns dann aber einen absolut ruhigen Urlaub beschert.

Ich mag etwas übersehen, aber mein Rekord liegt (bei einem wirklich kritischem Agent) wohl derzeit bei knapp 500 Programmzeilen an Prüfungen, bis die eigentlichen Aktionen dann starten (die ebenso peinlich überwacht werden). Der innere Vorbeimarsch für mich war: Dieser Agent löste eine Lösung eines anderen Unternehmens ab, deren Programm bei weniger Aktionen auf eine sechsstellige Anzahl von Dokumenten immer mindestens vier Stunden benötigte. Mein Programm war damit aber beim Erstlauf in knapp fünf Minuten fertig, und jeder weitere Lauf benötigt nur noch Sekunden. Die (extrem wichtigen) Prüfungen (error handling würde ich das noch nicht mal nennen, sondern "possible errros management") fallen da gar nicht ins Gewicht.

So, von der Antwort an Axel habe ich mich jetzt meilenweit entfernt (sorry) - es war "nur" ein Plädoyer für möglichst sicheren Code.

Bernhard

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete