Wieder mal ein XppFatal
Moderator: Moderatoren
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9358
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 101 Mal
- Danksagung erhalten: 361 Mal
- Kontaktdaten:
Re: Wieder mal ein XppFatal
Hallo, Hubert.
Selbstverständlich sollte die Errorsys sehr robust sein, also sich nicht darauf verlassen, dass Systematiken funktionieren, die selbst Fehlerursache sein können.
Ich sehe, mal von den Möglichkeiten abgesehen, auch keine Perspektive für kaufmännische Software, die Laufzeitfehler simpel loggt und dann einmal am Tag irgendein Protokoll erzeugt (was, unter uns gesagt, einmal zu oft ist). Das Fehlersystem erlaubt es, mit Situationen zu hantieren und diese auch zu umgehen, etwa jene, wenn Virenscanner kaskadieren und beim Öffnen vieler Dateien nacheinander Timeouts generieren. Es gestattet es, auf erwartete, aber nicht vorhandene Tabellenfelder oder Tabellen selbst zu reagieren, und auf vieles mehr. Ich habe unser Fehlersystem so weit ausgebaut, dass bei uns letztlich fast nur noch echte Fehler ankommen. Alles andere versucht die Errorsys, eigenständig zu korrigieren oder wenigstens Hinweise auf Behebungsmöglichkeiten zu geben. Und - was soll ich sagen? Es funktioniert.
Selbstverständlich sollte die Errorsys sehr robust sein, also sich nicht darauf verlassen, dass Systematiken funktionieren, die selbst Fehlerursache sein können.
Ich sehe, mal von den Möglichkeiten abgesehen, auch keine Perspektive für kaufmännische Software, die Laufzeitfehler simpel loggt und dann einmal am Tag irgendein Protokoll erzeugt (was, unter uns gesagt, einmal zu oft ist). Das Fehlersystem erlaubt es, mit Situationen zu hantieren und diese auch zu umgehen, etwa jene, wenn Virenscanner kaskadieren und beim Öffnen vieler Dateien nacheinander Timeouts generieren. Es gestattet es, auf erwartete, aber nicht vorhandene Tabellenfelder oder Tabellen selbst zu reagieren, und auf vieles mehr. Ich habe unser Fehlersystem so weit ausgebaut, dass bei uns letztlich fast nur noch echte Fehler ankommen. Alles andere versucht die Errorsys, eigenständig zu korrigieren oder wenigstens Hinweise auf Behebungsmöglichkeiten zu geben. Und - was soll ich sagen? Es funktioniert.
Herzlich,
Tom
Tom
- brandelh
- Foren-Moderator
- Beiträge: 15695
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 65 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Re: Wieder mal ein XppFatal
ich schrieb, dass das Programm beim Start nachsieht ob eine XppError.LOG bzw. XppFatal.LOG vorhanden ist und diese dann versendetTom hat geschrieben:die Laufzeitfehler simpel loggt und dann einmal am Tag irgendein Protokoll erzeugt
Das kam am Anfang alle paar Monate mal vor, bis alle Tippfehler beseitigt waren. Jetzt so gut wie gar nicht mehr.
Fehlende DATEN-Dateien moniert mein Programm beim Start, fehlende Indexe werden vor dem Zugriff automatisch erzeugt.
Meine CGI Anwendungen prüfen beim Datenimport ob die Struktur geändert wurde und bereinigt dies (Neue Felder anfügen, Feldlängen erweitern etc.)
Alles altmodisch vorsorglich ohne das Fehlersystem aufzurufen
Ich kann mir gut vorstellen, dass du mit deinen vielen verschiedenen Installationen / Versionen / Kunden hier mehr Aufwand treiben mußt.
Gruß
Hubert
Hubert
- Markus Walter
- Programmier-Gott
- Beiträge: 1018
- Registriert: Di, 24. Jan 2006 10:22
- Wohnort: Saarland
Re: Wieder mal ein XppFatal
Na das wäre doch mal eine Session wert...Tom hat geschrieben:Das Fehlersystem erlaubt es, mit Situationen zu hantieren und diese auch zu umgehen, etwa jene, wenn Virenscanner kaskadieren und beim Öffnen vieler Dateien nacheinander Timeouts generieren. Es gestattet es, auf erwartete, aber nicht vorhandene Tabellenfelder oder Tabellen selbst zu reagieren, und auf vieles mehr. Ich habe unser Fehlersystem so weit ausgebaut, dass bei uns letztlich fast nur noch echte Fehler ankommen. Alles andere versucht die Errorsys, eigenständig zu korrigieren oder wenigstens Hinweise auf Behebungsmöglichkeiten zu geben. Und - was soll ich sagen? Es funktioniert.
Gruß
Markus
Mitglied der XUG Saarland-Pfalz
Markus
Mitglied der XUG Saarland-Pfalz
- Wolfgang Ciriack
- Der Entwickler von "Deep Thought"
- Beiträge: 2934
- Registriert: Sa, 24. Sep 2005 9:37
- Wohnort: Berlin
- Hat sich bedankt: 13 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
- AUGE_OHR
- Marvin
- Beiträge: 12906
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 45 Mal
Re: Wieder mal ein XppFatal
du redest von "normalen" Fehler die im Fehler System "ankommen", das ist "trivial"Tom hat geschrieben:Ich traue dem OS genau das zu, was es auch können sollte. Und ich fahre exzellent damit.WOW ... dann "vertraust" du dem OS() aber ein Menge zu !
...
Fatals sind ein anderes Problem. Die etwas haarige Idee, nach einem Fatal einfach den Rechner zu booten, erinnert mich jedoch an Zeiten, wo man noch froh war, dass die Kiste überhaupt gestartet ist. Jemanden, der mir eine solche Software verkaufen würde, würde ich sofort nach der Auslieferung verklagen.
wenn ich aber mit der Win API "rum-spiele" und eine Pointer falsch setzte bekomme ich eine "buffer overflow" aber der Speicher wird nicht "bereinigt".
ein gutes Beispiel ist die System Image List oder Ownerdraw ... da möchte ich mal sehen wie du damit noch "weiterarbeiten" willst ...
wie ich schon sagte entstehen XppFatal.log wenn Xbase++ den Fehler nicht per
Code: Alles auswählen
XBPException():RaiseParameterXXX(xValue)
gruss by OHR
Jimmy
Jimmy
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2828
- Registriert: Fr, 10. Feb 2006 9:51
- Wohnort: Aachen
- Hat sich bedankt: 259 Mal
- Danksagung erhalten: 12 Mal
- Kontaktdaten:
Re: Wieder mal ein XppFatal
Tom,
wie schaffst Du es denn, die XppFatal.Log zu verändern?
Ich habe es nur durch den Trick geschafft, dass ich das Standardverzeichnis entsprechend einstelle, um zumindest den Pfad auf ein Verzeichnis mit Schreibberechtigung für die XppFatal.Log umbiegen zu können.
Uli
wie schaffst Du es denn, die XppFatal.Log zu verändern?
Ich habe es nur durch den Trick geschafft, dass ich das Standardverzeichnis entsprechend einstelle, um zumindest den Pfad auf ein Verzeichnis mit Schreibberechtigung für die XppFatal.Log umbiegen zu können.
Uli
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
Mitglied XuG Cologne
Mitglied XuG Osnabrück
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9358
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 101 Mal
- Danksagung erhalten: 361 Mal
- Kontaktdaten:
Re: Wieder mal ein XppFatal
Ich "spiele nicht rum", vor allem nicht im Kontext von Software, die im realen Leben eingesetzt wird. Ich käme niemals auf die Idee, das Ergebnis einer "Herumspielerei" an Kunden auszuliefern. Insofern ist dieses Szenario aus meiner Sicht irrelevant.wenn ich aber mit der Win API "rum-spiele"
Herzlich,
Tom
Tom
- AUGE_OHR
- Marvin
- Beiträge: 12906
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 45 Mal
Re: Wieder mal ein XppFatal
jaja ist schon gut ... ich spreche von der Entwicklungsphase wo man "die Limits auslotet" das man mal ein Xppfatal bekommt.Tom hat geschrieben:Ich "spiele nicht rum", vor allem nicht im Kontext von Software, die im realen Leben eingesetzt wird. Ich käme niemals auf die Idee, das Ergebnis einer "Herumspielerei" an Kunden auszuliefern. Insofern ist dieses Szenario aus meiner Sicht irrelevant.wenn ich aber mit der Win API "rum-spiele"
wenn es dann wirklich beim Kunden zu einem Xppfatal durch "meine" Xbase++ Application kommen sollte der NICHT vorher durch meine Errorsys angefangen wurde "dann" rate ich dazu es nochmals zu versuchen, nach einem "re-boot" !!!
sollte dann das selbe in "meiner" Xbase++ Application wieder passieren "dann" habe "ich" ein Problem.
aber kommen wir doch lieber auf das Problem von Jan zurück.
auch wenn der Hotfix Nr. 36 die Grenze anhebt haben wir mit Xbase++ ein grosses Problem weil wir ja nicht den Speicher für ein "riesiges" Array "anfordern" können.
Code: Alles auswählen
das geht nicht
LOCAL aArray := ARRAY[1000000]
das geht
LOCAL aArray := {}
FOR i := 1 To 1000000
AADD(aArray,"")
NEXT
aber Hubert schon sagte vielleicht benötigt man hier einen "anderen" Ansatz.
auf der Devcon erzählte mir "Frans Vermeulen" etwas von einem "riesigen" Report wo er mit 2 Million Daten arbeiten wollte ...
aber nicht mit einem Array sondern einem Bitmap (!!!)
jeder Pixel stellt ein Element dar und die Farbe (16 Mil.) den "Wert" und die "Berechnungen" erfolgen wohl per RGB Werte was Simon Burford ihm geliefert hat.
gruss by OHR
Jimmy
Jimmy
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2828
- Registriert: Fr, 10. Feb 2006 9:51
- Wohnort: Aachen
- Hat sich bedankt: 259 Mal
- Danksagung erhalten: 12 Mal
- Kontaktdaten:
Re: Wieder mal ein XppFatal
Coole Idee! Und was sagt die Performance dazuAUGE_OHR hat geschrieben:... auf der Devcon erzählte mir "Frans Vermeulen" etwas von einem "riesigen" Report wo er mit 2 Million Daten arbeiten wollte ...
aber nicht mit einem Array sondern einem Bitmap (!!!)
jeder Pixel stellt ein Element dar und die Farbe (16 Mil.) den "Wert" und die "Berechnungen" erfolgen wohl per RGB Werte was Simon Burford ihm geliefert hat.
Ich kann mir nicht vorstellen, dass man da mit xBase auf akzeptable Geschwindigkeiten kommt.
Uli
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
Mitglied XuG Cologne
Mitglied XuG Osnabrück
- AUGE_OHR
- Marvin
- Beiträge: 12906
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 45 Mal
Re: Wieder mal ein XppFatal
bei 1920 x 1080 x 16M = 8 GB.UliTs hat geschrieben:Coole Idee! Und was sagt die Performance dazu
Ich kann mir nicht vorstellen, dass man da mit xBase auf akzeptable Geschwindigkeiten kommt.
da er wohl mit den GDI(+) API arbeitet kann man damit ggf die GPU der GFK nutzen mit DDR-5 VRAM
soviel ich das verstanden habe, kann man mit der Xoanon Lib, schon diese Bitmap "Manipulationen" per GDI32 durchführen.
unter Win7 haben wir nun die 3-D Effecte was dann die GDI(+) API enthalten soll ... und die API zur Nutzung der GPU
was die Performance angeht bin ich mich nicht sicher ob die auch in dem "Zoom" Modul von Pablo drin steckt aber das hatte "Gamer" Qualität
aus der Satelliten Ansicht bis zum "Blumentopf" zu "zoomen" ging praktisch "stufenlos" ... hin und zurück.
sicherlich ist die Idee sehr speziell aber für "riesige" Array die mehr als 2 Millionen Handle benötigen sollte man unbedingt eine "pure" Xbase++ Lösung einsetzten
gruss by OHR
Jimmy
Jimmy
- brandelh
- Foren-Moderator
- Beiträge: 15695
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 65 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Re: Wieder mal ein XppFatal
Ich meinte eher, dass man die Daten anders vorhält.AUGE_OHR hat geschrieben:sicherlich ist die Idee sehr speziell aber für "riesige" Array die mehr als 2 Millionen Handle benötigen sollte man unbedingt eine "pure" Xbase++ Lösung einsetzten
Vor einiger Zeit hatte ich mal getestet was schneller geht, eine Datei in Arrays einlesen oder direkt (mit Index) zu verarbeiten.
Ich meine, dass ab 200 MB die interne Speicherverwaltung langsamer wird als die Indexzugriffe.
ASeek() sucht sequentiell !
Ein Ansatz wäre z.B. eine Klasse oder Struktur, deren Elemente in einem eindimensionalen Array gespeichert werden.
Angenommen 100 Elemente in der zweiten Dimension mit Text und 1000 Zeilen ... würde normalerweise 100*1000 Speicherhandles verbraten.
Sonst nur 1000 mit je einem Objekt.
Ginge es nur um die Geschwindigkeit könnte man die "Hash Table Functions" von Pablo nutzen.
Wie gesagt, man sollte den Ansatz komplett überdenken.
Gruß
Hubert
Hubert