PureBoard

thminz hat geschrieben:alles andere ist nicht nachvollziehbar wo der Fehler entstand!

Auch mit aktivierten CompilerOptionen ist lediglich nachvollziehbar, wo der Fehler auftrat, nicht wo er
entstand!
Die CompilerOptionen aktiviert man nur für eine Testversion oder Beta, um evtl. noch vorhandene,
noch nicht gefundene, Fehler finden zu können.

Bei einem RC kann man dann die Zeilennummern-Unterstützung der OnError Lib deaktivieren.
Abstürze lassen sich abfangen, so das man das Programm dann kontrolliert beenden kann (vorher
aufräumen, speichern usw.). Der Kunde kann einem dann über den Fehler berichten, eine Beschreibung
seines Tuns unmittelbar vor dem Absturz ist meist genauso hilfreich wie die Zeilennummer.

Gruß
Thomas

STARGÅTE hat geschrieben:Wenn dein Code OnError braucht, da "oft" Fehler kommen, dann ist er eh noch nicht bereit veröffendlicht zu werden.
Somit ist auch die Geschwindigkeit egal.
OnError ersetzt nicht den Debugger!

Zitat:

Diese Bibliothek kann mit Hilfe der Befehle ErrorFile() und ErrorLine() Informationen über die Quellcode-Datei und die Zeile, bei der der Fehler auftrat, liefern. Allerdings nur, wenn dieses Feature während des Kompilierens aktiviert wurde (es verursacht eine sehr geringe Verlangsamung der Ausführungsgeschwindigkeit, um die Zeilennummern zu beobachten).

Was läuft denn hier schon wieder? Es ist doch wohl
seine Entscheidung, ob er sich beim Trade-off zwischen
Zeit und Fehlerauffindbarkeit für letzteres entscheidet.

"OnError ersetzt nicht den Debugger" ist ja wohl klar, aber
dass der Code nicht mit OnError-Support veröffentlicht
werden soll, ist ganz einfach falsch. Das kann jeder für
sich entscheiden. Für viele Applikationen spielt die eingebüsste
Geschwindigkeit keine Rolle, dann kann man sich ohne
schlechtes Gewissen für genauere (IMO viel genauere)
Fehlerbeschreibungen entscheiden.
Was IMO angebracht wäre, ist ein Enable/DisableOnError
zum temporären Deaktivieren dieses Features.

greetz
Remi

Die einzigen Fehler, die von der OnError Lib aufgespürt werden können, DivByZero, IMA usw. lassen
sich eigentlich von jedem erfahrenen Programmierer Mithilfe des Debuggers zu 99% beseitigen.
Für die logischen Fehler, die zum Schluss meist übrig bleiben ist OnError sowieso unnütz. Ich denke
mal, so hat STARGÅTE es gemeint.

Aber wie, wann und ob er OnError einsetzt, sollte jeder für sich und seine Anwendung entscheiden

ts-soft hat geschrieben:Die einzigen Fehler, die von der OnError Lib aufgespürt werden können, DivByZero, IMA usw. lassen
sich eigentlich von jedem erfahrenen Programmierer Mithilfe des Debuggers zu 99% beseitigen.
Für die logischen Fehler, die zum Schluss meist übrig bleiben ist OnError sowieso unnütz. Ich denke
mal, so hat STARGÅTE es gemeint.

Aber wie, wann und ob er OnError einsetzt, sollte jeder für sich und seine Anwendung entscheiden

Hätte es fast so stehen lassen, möchte aber noch
diese 1% betonen, die eben schwierig mit Debugger
aufzufinden sind. Dann ist man über eine Zeilenangabe
doch recht glücklich. IMAs auf Grund von nicht oder
falsch initialisierten Daten sind gar nicht mal so selten
und leider oft auch Input abhängig.

Und dann gibt's da noch die wenigen, die PB im
Zusammenhang mit Deadlines verwenden und so
gezwungenermassen die User als Debugger missbrauchen

greetz
Remi