Fehlerbehandlung

Übersicht

BlitzBasic

Allgemein

	Eingeproggt Betreff: Fehlerbehandlung	Sa, Jan 28, 2012 20:07 Antworten mit Zitat
Servus, ich grüble den ganzen Nachmittag herum, wie man wohl am besten mit Fehlern umgeht in BB. Weiß nicht ob ich darüber lachen oder weinen soll dass mir das erst jetzt ein Problem wird. Aber nachdem ich Exceptions von Java kennen gelernt hab fällt mir der umgang mit BB richtig schwer diesbezüglich Folgende Möglichkeiten sehe ich in BB: RuntimeError: Nein danke, das ganze Programm in die Luft jagen nur weil irgendwas nicht passt? Auf das man logischerweise sogar selber draufgekommen ist? (Ansonsten wüßte man ja nicht wo der RuntimeError zu melden wäre ) Dafür wäre das nur eine bequeme Zeile. Irgendwelche Versuche, Fehler auszubessern oder versuchen damit zu leben auch wenn dann was falsches raus kommt... immer noch besser als Programmabsturz, aber halt auch irgendwie blöd... noch dazu wo man den User dann ja nicht darüber informiert was schief gelaufen is. Return True wenn alles klappt, Return False im Fehlerfall: Meine bisher bevorzugte Lösung, aber bei mehr oder weniger jeden Funktionsaufruf das Ergebnis auf =0 abzufragen is halt auch n bissi blöd Ich habs so weit gedreht, dass die 0 für "Fehler" in allen Funktionen "weiter geleitet" wird, so dass man am Ende immer noch ganz bequem auf 0 prüfen kann und im besten Fall in einer globalen Variable eine Fehlerbeschreibung hat. Aber auch das "Weiterreichen" der Rückgabewerte is mühsam... Also zur Veranschaulichung: BlitzBasic: [AUSKLAPPEN] [EINKLAPPEN] Function a() [...] If fehler Then Return 0 [...] Return 1 End Function Function b() [...] If a()=0 Then Return 0 [...] Return 1 End Function (und natürlich Aufruf von b() ist hier interessant) Was macht ihr so bzw. würdet ihr mir empfehlen? Also mein Ziel wäre, dass Fehler möglichst gut beschrieben ausgespuckt werden und das Programm im Fehlerfall aber nicht zwangsläufig krachen geht. mfG, Christoph.
Gewinner des BCC 18, 33 und 65 sowie MiniBCC 9

Eingeproggt

Betreff: Fehlerbehandlung

Sa, Jan 28, 2012 20:07
Antworten mit Zitat

Servus,

ich grüble den ganzen Nachmittag herum, wie man wohl am besten mit Fehlern umgeht in BB. Weiß nicht ob ich darüber lachen oder weinen soll dass mir das erst jetzt ein Problem wird. Aber nachdem ich Exceptions von Java kennen gelernt hab fällt mir der umgang mit BB richtig schwer diesbezüglich Sad

Folgende Möglichkeiten sehe ich in BB:

RuntimeError

: Nein danke, das ganze Programm in die Luft jagen nur weil irgendwas nicht passt? Auf das man logischerweise sogar selber draufgekommen ist? (Ansonsten wüßte man ja nicht wo der RuntimeError zu melden wäre Wink

)
Dafür wäre das nur eine bequeme Zeile.

Irgendwelche Versuche, Fehler auszubessern oder versuchen damit zu leben auch wenn dann was falsches raus kommt... immer noch besser als Programmabsturz, aber halt auch irgendwie blöd... noch dazu wo man den User dann ja nicht darüber informiert was schief gelaufen is.

Return

True wenn alles klappt, Return False im Fehlerfall: Meine bisher bevorzugte Lösung, aber bei mehr oder weniger jeden Funktionsaufruf das Ergebnis auf =0 abzufragen is halt auch n bissi blöd Sad

Ich habs so weit gedreht, dass die 0 für "Fehler" in allen Funktionen "weiter geleitet" wird, so dass man am Ende immer noch ganz bequem auf 0 prüfen kann und im besten Fall in einer globalen Variable eine Fehlerbeschreibung hat. Aber auch das "Weiterreichen" der Rückgabewerte is mühsam... Also zur Veranschaulichung:
BlitzBasic: [AUSKLAPPEN]

Function a()
  [...]
  If fehler Then Return 0
  [...]
  Return 1
End Function

Function b()
  [...]
  If a()=0 Then Return 0
  [...]
  Return 1
End Function

(und natürlich Aufruf von b() ist hier interessant)

Was macht ihr so bzw. würdet ihr mir empfehlen? Also mein Ziel wäre, dass Fehler möglichst gut beschrieben ausgespuckt werden und das Programm im Fehlerfall aber nicht zwangsläufig krachen geht.

mfG, Christoph.

Gewinner des BCC 18, 33 und 65 sowie MiniBCC 9

	Xeres Moderator	Sa, Jan 28, 2012 20:14 Antworten mit Zitat
Du könntest ein Logfile schreiben - das ist zumindest super, um die Fehler zurück zu verfolgen. Falsche Benutzereingaben sollten zumindest keinen Absturz verursachen - ein Infofenster, sollte nicht zu schwer zu realisieren sein, das wäre aber nicht zwangsweise nötig.
Win10 Prof.(x64)/Ubuntu 16.04\|CPU 4x3Ghz (Intel i5-4590S)\|RAM 8 GB\|GeForce GTX 960 Wie man Fragen richtig stellt \|\| "Es geht nicht" \|\| Video-Tutorial: Sinus & Cosinus THERE IS NO FAIR. THERE IS NO JUSTICE. THERE IS JUST ME. (Death, Discworld)

Xeres

Moderator

Sa, Jan 28, 2012 20:14
Antworten mit Zitat

Du könntest ein Logfile schreiben - das ist zumindest super, um die Fehler zurück zu verfolgen.
Falsche Benutzereingaben sollten zumindest keinen Absturz verursachen - ein Infofenster, sollte nicht zu schwer zu realisieren sein, das wäre aber nicht zwangsweise nötig.

Win10 Prof.(x64)/Ubuntu 16.04|CPU 4x3Ghz (Intel i5-4590S)|RAM 8 GB|GeForce GTX 960
Wie man Fragen richtig stellt || "Es geht nicht" || Video-Tutorial: Sinus & Cosinus
THERE IS NO FAIR. THERE IS NO JUSTICE. THERE IS JUST ME. (Death, Discworld)

	BB-Freak	Sa, Jan 28, 2012 20:23 Antworten mit Zitat
DebugLog währe wohl das beste(Leider sieht das der Benutzer nicht)

BB-Freak

Sa, Jan 28, 2012 20:23
Antworten mit Zitat

DebugLog währe wohl das beste(Leider sieht das der Benutzer nicht) Wink

	Eingeproggt	Sa, Jan 28, 2012 20:44 Antworten mit Zitat
Logfile ist auch eine feine Idee, stimmt. Dann muss der User halt selbst nachforschen was er falsch gemacht hat, dafür hätte er die meisten Infos. @Freak: Debuglog kenn ich, gibts sogar in B3D auch Benutz ich eh schon, aber is halt für spätere Anwendung nicht geeignet weil jemand ohne BB nicht in den Debuglog reinschauen kann. Außerdem nervt es mich langsam tierisch dass mein aktuelles Projekt fast um Faktor 20 langsamer ist im Debugmode mfG, Christoph.
Gewinner des BCC 18, 33 und 65 sowie MiniBCC 9

Eingeproggt

Sa, Jan 28, 2012 20:44
Antworten mit Zitat

Logfile ist auch eine feine Idee, stimmt. Dann muss der User halt selbst nachforschen was er falsch gemacht hat, dafür hätte er die meisten Infos.

@Freak: Debuglog kenn ich, gibts sogar in B3D auch Wink

Benutz ich eh schon, aber is halt für spätere Anwendung nicht geeignet weil jemand ohne BB nicht in den Debuglog reinschauen kann. Außerdem nervt es mich langsam tierisch dass mein aktuelles Projekt fast um Faktor 20 langsamer ist im Debugmode Shocked

mfG, Christoph.

Gewinner des BCC 18, 33 und 65 sowie MiniBCC 9

	BB-Freak	Sa, Jan 28, 2012 20:52 Antworten mit Zitat
Achso Der Benutzer muss halt wissen, dass es eine Logfile gibt

BB-Freak

Sa, Jan 28, 2012 20:52
Antworten mit Zitat

Achso

Der Benutzer muss halt wissen, dass es eine Logfile gibt Wink

	BIG BUG	Sa, Jan 28, 2012 22:53 Antworten mit Zitat
Das kommt immer auf den Fehler drauf an, wie Du da reagieren solltest. Also "fatale" Fehler, wie dass z.B. eine Datei nicht geladen werden kann dürfen durchaus zu einem RuntimeError mit entsprechender Meldung (inkl. Dateiname!) führen, da es ja früher oder später eh zu einer MAV kommen würde. Wenn z.B. das Netzwerk nicht initialisiert werden kann, wäre eine Benutzermeldung angebracht, das Spiel müsste aber nicht unbedingt gleich komplett abstürzen. Auf Fehler wie z.B. dass der Spieler an eine Position gekommen ist an die er nicht kommen sollte muss normalerweise nicht reagiert werden. Falls soetwas vermehrt auftritt ist im Idealfall der Bug zu korrigieren anstelle durch Code das Ding zu umgehen...
B3D-Exporter für Cinema4D!(V1.4) MD2-Exporter für Cinema4D!(final)

BIG BUG

Sa, Jan 28, 2012 22:53
Antworten mit Zitat

Das kommt immer auf den Fehler drauf an, wie Du da reagieren solltest.
Also "fatale" Fehler, wie dass z.B. eine Datei nicht geladen werden kann dürfen durchaus zu einem RuntimeError mit entsprechender Meldung (inkl. Dateiname!) führen, da es ja früher oder später eh zu einer MAV kommen würde.
Wenn z.B. das Netzwerk nicht initialisiert werden kann, wäre eine Benutzermeldung angebracht, das Spiel müsste aber nicht unbedingt gleich komplett abstürzen.
Auf Fehler wie z.B. dass der Spieler an eine Position gekommen ist an die er nicht kommen sollte muss normalerweise nicht reagiert werden. Falls soetwas vermehrt auftritt ist im Idealfall der Bug zu korrigieren anstelle durch Code das Ding zu umgehen...

B3D-Exporter für Cinema4D!(V1.4)
MD2-Exporter für Cinema4D!(final)

	PacMani	So, Jan 29, 2012 0:38 Antworten mit Zitat
Sinnvolle Fehlerbehandlung? Da kann ich nur den wenig hilfreichen Tipp geben, von Blitz wegzukommen

PacMani

So, Jan 29, 2012 0:38
Antworten mit Zitat

Sinnvolle Fehlerbehandlung?
Da kann ich nur den wenig hilfreichen Tipp geben, von Blitz wegzukommen Wink

	Jan_ Ehemaliger Admin	So, Jan 29, 2012 23:09 Antworten mit Zitat
Pac-Man, wo soll die Fehlerbehandlung denn besser sein? Sehr off-Topic. Das einzige unter jeder Programmiersprache, ist ordentlich zu coden. Egal welche Programmiersprache, wenn man Programme hat, die mehrere Hundert Leute täglich anwenden ist so etwas, wie Programm läuft trotz fehler weiter nicht AKZEPTABEL. ein Programmabsturz ist kein Problem, wenn der Supporter an der Absturzmeldung erkennt, woran es liegt. und leider nützen da Standard Meldungen nix. Oder, was denkt denkt, mann wenn da eine 60 Jahre alte frau, aus ihren erinnerungen eine Englische Meldung ansagt -- epic Fail. Fehler müssen voim Programmierer abgefangen werden, dort wo sie passieren können und ordentlich angezeigt werden.
between angels and insects

Jan_

Ehemaliger Admin

So, Jan 29, 2012 23:09
Antworten mit Zitat

Pac-Man, wo soll die Fehlerbehandlung denn besser sein?
Sehr off-Topic.

Das einzige unter jeder Programmiersprache, ist ordentlich zu coden. Egal welche Programmiersprache, wenn man Programme hat, die mehrere Hundert Leute täglich anwenden ist so etwas, wie Programm läuft trotz fehler weiter nicht AKZEPTABEL.

ein Programmabsturz ist kein Problem, wenn der Supporter an der Absturzmeldung erkennt, woran es liegt. und leider nützen da Standard Meldungen nix. Oder, was denkt denkt, mann wenn da eine 60 Jahre alte frau, aus ihren erinnerungen eine Englische Meldung ansagt -- epic Fail.

Fehler müssen voim Programmierer abgefangen werden, dort wo sie passieren können und ordentlich angezeigt werden.

between angels and insects

	Propellator	So, Jan 29, 2012 23:14 Antworten mit Zitat
Fehler sollten nur zum Programmabsturz führen, wenn sie fatal sind. Für alles andere gibt es Error-Logs. Man denke sich, was passieren würde, wenn Microsoft Word abstürzen würde nur weil man keine gültige Schriftfarbe ausgewählt hat. Wusch, Dokument weg, da bringt auch der beste Support nichts. Programme sollten irgendwie kommunizieren, dass es ein Problem gab, da stimme ich dir zu. Aber sie sollen es nicht gleich so zelebrieren.
Propellator - Alles andere ist irrelephant. Elefanten sind die Könige der Antarktis.

Propellator

So, Jan 29, 2012 23:14
Antworten mit Zitat

Fehler sollten nur zum Programmabsturz führen, wenn sie fatal sind. Für alles andere gibt es Error-Logs. Man denke sich, was passieren würde, wenn Microsoft Word abstürzen würde nur weil man keine gültige Schriftfarbe ausgewählt hat. Wusch, Dokument weg, da bringt auch der beste Support nichts.

Programme sollten irgendwie kommunizieren, dass es ein Problem gab, da stimme ich dir zu. Aber sie sollen es nicht gleich so zelebrieren.

Propellator - Alles andere ist irrelephant.
Elefanten sind die Könige der Antarktis.

	ZaP	Mo, Jan 30, 2012 11:40 Antworten mit Zitat
Jau, Fehler selbst abfangen, immer prüfen, ob alles, was so von "außen" kommt auch so stimmt, wie es ist (und nicht erst, wenn das Programm schon halb fertig ist, sonst wird das ein Haufen Arbeit...). Wenn's nicht stimmt, Fehler ins Log, und dann muss es ja vielleicht nicht gleich mit MAV enden, sondern mit einer "eigenen Fehlerausgabe", so das man z.B. zurück ins Hauptmenü geworfen wird, wo dann in einem Fensterchen ein Fehler steht. Ansonsten vermisse ich ja auch Try/Catch in BB
Starfare: Worklog, Website (download)

ZaP

Mo, Jan 30, 2012 11:40
Antworten mit Zitat

Jau, Fehler selbst abfangen, immer prüfen, ob alles, was so von "außen" kommt auch so stimmt, wie es ist (und nicht erst, wenn das Programm schon halb fertig ist, sonst wird das ein Haufen Arbeit...).
Wenn's nicht stimmt, Fehler ins Log, und dann muss es ja vielleicht nicht gleich mit MAV enden, sondern mit einer "eigenen Fehlerausgabe", so das man z.B. zurück ins Hauptmenü geworfen wird, wo dann in einem Fensterchen ein Fehler steht.
Ansonsten vermisse ich ja auch Try/Catch in BB Razz

Starfare: Worklog, Website (download)

	Jan_ Ehemaliger Admin	Mo, Jan 30, 2012 14:11 Antworten mit Zitat
Jap, klar, wenn eine Schriftart fehlt, sollte es nicht abstürzen, Aber eine Message sollte komme, mit "Schriftart xy konnte nicht geladen werden." Try und Catch ist das BÖSESTE überhaupt! Es gibt für BB einen API aufruf, der ein Notify macht, also, Nachricht, ohne abzustürzen, dass wäre meine Waffe, der wahl, bei der Kommunikation mit dem Nutzer.
between angels and insects

Jan_

Ehemaliger Admin

Mo, Jan 30, 2012 14:11
Antworten mit Zitat

Jap, klar, wenn eine Schriftart fehlt, sollte es nicht abstürzen, Aber eine Message sollte komme, mit "Schriftart xy konnte nicht geladen werden."
Try und Catch ist das BÖSESTE überhaupt!

Es gibt für BB einen API aufruf, der ein Notify macht, also, Nachricht, ohne abzustürzen, dass wäre meine Waffe, der wahl, bei der Kommunikation mit dem Nutzer.

between angels and insects

	ZaP	Mo, Jan 30, 2012 16:49 Antworten mit Zitat
Naja, ich finde Try/Catch ist schon ganz angenehm. In BB handhabe ich das so, dass wenn z.B. beim Laden eines Levels ein Fehler auftreten kann, die Ladefunktion eine globale Fehler$ mit einem Fehlerstring versieht, und alle nachfolgenden Funktionen dann prüfen, ob der Fehlerstring leer ist, und wenn nicht, einfach abbrechen. In der Hauptschleife wird dann die entsprechende Fehleranzeige ausgelöst (aber ohne RuntimeError, z.B. auf einem Fenster der Ingame-GUI), so kann der Spieler dann versuchen, ein anderes Level zu laden.
Starfare: Worklog, Website (download)

ZaP

Mo, Jan 30, 2012 16:49
Antworten mit Zitat

Naja, ich finde Try/Catch ist schon ganz angenehm. In BB handhabe ich das so, dass wenn z.B. beim Laden eines Levels ein Fehler auftreten kann, die Ladefunktion eine globale Fehler$ mit einem Fehlerstring versieht, und alle nachfolgenden Funktionen dann prüfen, ob der Fehlerstring leer ist, und wenn nicht, einfach abbrechen. In der Hauptschleife wird dann die entsprechende Fehleranzeige ausgelöst (aber ohne RuntimeError, z.B. auf einem Fenster der Ingame-GUI), so kann der Spieler dann versuchen, ein anderes Level zu laden.

Starfare: Worklog, Website (download)

	FireballFlame	Mo, Jan 30, 2012 18:41 Antworten mit Zitat
Jan_ hat Folgendes geschrieben: Try und Catch ist das BÖSESTE überhaupt! Woher nimmst du denn diese Behauptung? Try und Catch sind genau dazu da, Code gegen eventuell auftretende Fehler zu sichern, und zwar ohne dass a) gleich das gesamte Programm abstürzt oder man b) in jede einzelne Zeile eine eigene If/Then-Abfrage o.ä. schreiben muss. Genau das sind die beiden hässlichen Varianten, die Eingeproggt auch im Startpost beschrieben hat. Findest du die etwa gut?? Mir fällt leider auch keine sehr gute Methode ein, was man da in BB machen könnte; zumindest um die ständige Abfrage wirst du wohl nicht herumkommen...
PC: Intel Core i7 @ 4x2.93GHz \| 6 GB RAM \| Nvidia GeForce GT 440 \| Desktop 2x1280x1024px \| Windows 7 Professional 64bit Laptop: Intel Core i7 @ 4x2.00GHz \| 8 GB RAM \| Nvidia GeForce GT 540M \| Desktop 1366x768px \| Windows 7 Home Premium 64bit

FireballFlame

Mo, Jan 30, 2012 18:41
Antworten mit Zitat

Jan_ hat Folgendes geschrieben:

Try und Catch ist das BÖSESTE überhaupt!

Woher nimmst du denn diese Behauptung?
Try und Catch sind genau dazu da, Code gegen eventuell auftretende Fehler zu sichern, und zwar ohne dass a) gleich das gesamte Programm abstürzt oder man b) in jede einzelne Zeile eine eigene If/Then-Abfrage o.ä. schreiben muss. Genau das sind die beiden hässlichen Varianten, die Eingeproggt auch im Startpost beschrieben hat. Findest du die etwa gut??

Mir fällt leider auch keine sehr gute Methode ein, was man da in BB machen könnte; zumindest um die ständige Abfrage wirst du wohl nicht herumkommen...

	BIG BUG	Di, Jan 31, 2012 1:23 Antworten mit Zitat
Naja, wie gesagt sollte abhängig vom Fehler reagiert werden und man sollte dabei die Kirche auch im Dorf lassen. BlitzBasic ist schließlich für Computerspiele gedacht und nicht für Mond-Missionen... Am Schluß fängt man sich durch unnötige Fehlerbehandlung und den dadurch unübersichtlicheren Code noch einen blöden Bug ein.
B3D-Exporter für Cinema4D!(V1.4) MD2-Exporter für Cinema4D!(final)

BIG BUG

Di, Jan 31, 2012 1:23
Antworten mit Zitat

Naja, wie gesagt sollte abhängig vom Fehler reagiert werden und man sollte dabei die Kirche auch im Dorf lassen. BlitzBasic ist schließlich für Computerspiele gedacht und nicht für Mond-Missionen... Am Schluß fängt man sich durch unnötige Fehlerbehandlung und den dadurch unübersichtlicheren Code noch einen blöden Bug ein.

B3D-Exporter für Cinema4D!(V1.4)
MD2-Exporter für Cinema4D!(final)

	Eingeproggt	Di, Jan 31, 2012 14:45 Antworten mit Zitat
Ich weiß nicht, wie weit eure Antworten noch zu meiner Frage gehören oder ob da schon die ersten "Paradigmen-Kriege" zwischen Java und BB in den Startlöchern stehen - ich antworte trotzdem auch mal @Try-Catch: Klar ist es nicht das Allheilmittel und schon gar nicht sollte man Dinge, die keine Fehler sind damit behandeln! Aber in einigen Fällen - und um genau die geht es mir - ist try-catch das Mittel der Wahl. Man nehme folgendes Beispiel: BlitzBasic: [AUSKLAPPEN] [EINKLAPPEN] Function machwas(x.Type) If x\Field=irgendwas_bestimmtes Then Return 0 ;Fehler EndIf ;mach das Return machwas(x.child) End Function Das soll ein extrem gekürztes Beispiel einer Rekursion sein. Egal ob Rekursion oder das Abarbeiten von hunderten und tausenden Einträgen... überall darauf zu achten ob Ergebnis=0 ist nicht nur für den Programmierer, auch (in gaaaanz geringem Umfang) für den Rechner umständlich. Statt Return 0 wäre hier ein "throw exception" doch sehr angebracht. Ich gehe sogar soweit, zu überlegen ob sich nicht mittels GoTo ein ähnliches Verhalten hinbiegen lässt... Aber keine Angst, das soll nur eine weitere Option aufzeigen die ich aber NICHT verfolge. Weil dass Goto böse is da sind wir uns alle einig @BigBug: Bin ganz deiner Meinung... nur tendiere ich dazu, BB als "nicht-Spiel-Sprache" zu missbrauchen ^^ (Ganz einfach weil man für Spiele kreativ sein muss und in der heutigen Zeit graphische Leckerbissen servieren muss - beides liegt mir nicht ) Eine selbst kreierte MessageBox oder n Notify mit "Map konnte nicht geladen werden" ist für mich nicht ganz ausreichend. Wie bei obigem Beispiel gezeigt geht es mir eher um Fehler in der Verarbeitung von Eingaben (Text) oder event. auch um das Abfangen von Fehlern die ich selbst beim Parsen gemacht hab (und die ich dann anschließend analysieren können soll). Wenn so n Fehler auftritt dann ist mein Ziel dass die Verarbeitung abgebrochen wird, aber das Programm für ne neue Aufgabe weiterhin bereit steht. @Alle: Ich habs mehr oder weniger gelöst... mit einer Mischung aus all euren Beiträgen Überall Return 0 & abfragen & im Fehlerfall Logdatei schreiben. mfG, Christoph
Gewinner des BCC 18, 33 und 65 sowie MiniBCC 9

Eingeproggt

Di, Jan 31, 2012 14:45
Antworten mit Zitat

Ich weiß nicht, wie weit eure Antworten noch zu meiner Frage gehören oder ob da schon die ersten "Paradigmen-Kriege" zwischen Java und BB in den Startlöchern stehen - ich antworte trotzdem auch mal Wink

@Try-Catch:
Klar ist es nicht das Allheilmittel und schon gar nicht sollte man Dinge, die keine Fehler sind damit behandeln! Aber in einigen Fällen - und um genau die geht es mir - ist try-catch das Mittel der Wahl. Man nehme folgendes Beispiel:
BlitzBasic: [AUSKLAPPEN]

Function machwas(x.Type)
  If x\Field=irgendwas_bestimmtes Then
    Return 0 ;Fehler
  EndIf
  ;mach das
  Return machwas(x.child)
End Function

Das soll ein extrem gekürztes Beispiel einer Rekursion sein. Egal ob Rekursion oder das Abarbeiten von hunderten und tausenden Einträgen... überall darauf zu achten ob Ergebnis=0 ist nicht nur für den Programmierer, auch (in gaaaanz geringem Umfang) für den Rechner umständlich. Statt Return 0 wäre hier ein "throw exception" doch sehr angebracht.
Ich gehe sogar soweit, zu überlegen ob sich nicht mittels GoTo ein ähnliches Verhalten hinbiegen lässt... Aber keine Angst, das soll nur eine weitere Option aufzeigen die ich aber NICHT verfolge. Weil dass Goto böse is da sind wir uns alle einig Wink

@BigBug:
Bin ganz deiner Meinung... nur tendiere ich dazu, BB als "nicht-Spiel-Sprache" zu missbrauchen ^^ (Ganz einfach weil man für Spiele kreativ sein muss und in der heutigen Zeit graphische Leckerbissen servieren muss - beides liegt mir nicht Razz

) Eine selbst kreierte MessageBox oder n Notify mit "Map konnte nicht geladen werden" ist für mich nicht ganz ausreichend. Wie bei obigem Beispiel gezeigt geht es mir eher um Fehler in der Verarbeitung von Eingaben (Text) oder event. auch um das Abfangen von Fehlern die ich selbst beim Parsen gemacht hab (und die ich dann anschließend analysieren können soll). Wenn so n Fehler auftritt dann ist mein Ziel dass die Verarbeitung abgebrochen wird, aber das Programm für ne neue Aufgabe weiterhin bereit steht.

@Alle:
Ich habs mehr oder weniger gelöst... mit einer Mischung aus all euren Beiträgen Wink

Überall Return 0 & abfragen & im Fehlerfall Logdatei schreiben.

mfG, Christoph

Gewinner des BCC 18, 33 und 65 sowie MiniBCC 9

	Jan_ Ehemaliger Admin	Di, Jan 31, 2012 16:35 Antworten mit Zitat
Ich würde Recursion auch nicht unbedingt verwenden, weil sie schwer zu teilen ist und den CPU Stack stark belastet. In Recursion gibt es bei BB oft Probleme, mit Weitergabe der Rückgabewerte. Du solltest dafür einen Typen anlegen, wo alle weiterschritte drinne gespeichert sind. In Bmax, eine Liste.
between angels and insects

Jan_

Ehemaliger Admin

Di, Jan 31, 2012 16:35
Antworten mit Zitat

Ich würde Recursion auch nicht unbedingt verwenden, weil sie schwer zu teilen ist und den CPU Stack stark belastet. In Recursion gibt es bei BB oft Probleme, mit Weitergabe der Rückgabewerte. Du solltest dafür einen Typen anlegen, wo alle weiterschritte drinne gespeichert sind.
In Bmax, eine Liste.

between angels and insects

Übersicht

BlitzBasic

Allgemein

Nach Oben

BlitzBasic Portal

Fehlerbehandlung

Betreff: Fehlerbehandlung