Diskussion:Laufzeitfehler

Wie kann ich einen Laufzeitfehler beheben???

So, habe gerade was dazu in den Artikel eingebaut. Verständlich so? Regnaron 13:28, 12. Jun 2005 (CEST)

Behebung durch Exception Handling

Was ist bei Sprachen wie z.B. C, wo es kein Exception Handling gibt? Meiner Meinung nach müsste man den Begriff zu etwas wie "Fehler voraussschauend abfangen" erweitern. --Kasper4711 13:32, 2. Aug 2005 (CEST)

So, habe das ganze mal etwas umgeschrieben. So besser? Regnaron 16:29, 2. Aug 2005 (CEST)

Jupp, damit kann ich leben. --Kasper4711 09:00, 3. Aug 2005 (CEST)

Merge in Laufzeit

Zu den Lemmas Laufzeitfehler und Laufzeit habe ich etwas unter Diskussion:Laufzeit geschrieben, was die Auflösung dieses Artikels betrifft. --Benji 00:44, 16. Jan. 2007 (CET)

Definition, Abgrenzung zu normalem Programmfehler

Ist unter Laufzeitfehler jeder Fehler zu verstehen, der einfach beim Programmlauf auftritt? Bei den Beispielen werden nur 'technische Fehler' aufgeführt, durch die das Programm i.d.R. nicht ausführbar ist oder eine exception eintritt. Als Gegensatz sind Fehler definiert, die der Compiler erkennt. Es gibt aber auch eine dritte Kategorie: Ist ein 'stinknormaler' Programmfehler (plus statt minus, falsche Abfrage, Variablennamen vertauscht etc.), der beim Testen nicht erkannt wurde und der erst zur Laufzeit (oder danach) 'bemerkt' wird, i.d.R. ohne Abbruch, auch ein Laufzeitfehler? Nach der aktuellen Definition wäre das so. Wenn aber nur technische Fehler gemeint sind, müsste dies noch präzisiert und die beschriebene Fehlersituation abgegrenzt werden. Es geht also darum, ob das Kriterium 'zur Laufzeit auftreten' korrekt und vollständig ist. --VÖRBY (Diskussion) 19:15, 7. Jun. 2013 (CEST)

Mein Informatik-Lexikon beschreibt LZF als "Fehler, die erst bei der Ausführung des Programms durch den Computer gemeldet werden". Das hieße, es kann sich nur um technische Fehler handeln, denn nur solche kann der 'Computer' feststellen. Umkehrschluss: Einfache Programmfehler - die der Computer nicht melden kann - gelten nicht als 'Laufzeitfehler'. Dies sollte man in der Einleitung abgrenzend ergänzen.

PS: Ich denke man kann diese Definition als durch den Computer gemeldet interpretieren, nicht als bei Ausführung durch den Computer ... von Irgendwem gemeldet. --VÖRBY (Diskussion) 11:23, 20. Jun. 2013 (CEST)

Nach der üblichen (mir bekannten) Definition, sind Laufzeitfehler nur solche, die eine Terminierung des Programms zur Folge haben. Falsche Ergebnisse ("+" statt "-" sind Logikfehler (s.a. http://www.dickbaldwin.com/alice/Alice0155.htm). Aber auch hier gibt es wohl auch eine andere Sicht: http://www.techterms.com/definition/runtime_error (sogar Memory Leaks sind demnach Laufzeitfehler, diese Aussage halte ich allerdings nicht für haltbar, sie nährt den Verdacht, dass der Verfasser nicht alles versteht, wovon er schreibt). Im übrigen ist das nicht das einzige, was an diesem Artikel suboptimal ist.--Cactus26 (Diskussion) 15:33, 20. Jun. 2013 (CEST)

Nachtrag. Habe in der mir verfügbaren Lit. ein wenig gesucht: In Fischer, Hofer: Lexikon der Informatik (2008) findet sich folgendes:

Auf einer korrekten Syntax beruhender, aber semantischer, logischer Fehler (z.B. eine Division durch 0).

Bislang fand ich das Lexikon eigentlich ganz gut, aber die Formulierung "ein Fehler, der auf einer korrekten Syntax beruht" ist schon sehr speziell. Klar ist, dass diese Def. Logikfehler einschließt, was ich sonderbar finde. Hier wäre vlt. tats. ein i.e.S. und i.w.S. angebracht (denn der eine Fall ist Teilmenge des anderen), es scheint ja so:

1. i.e.S.: Fehler, der Programmabbruch zur Folge hat
2. i.w.S.: jeder Fehler, der zur Laufzeit auftritt, also alles außer "Syntaxfehler" (genaugenommen eigentlich Fehlern, die während des Compile aufgedeckt werden)

Man müsste hier aber wohl auch sehr ausführlich recherchieren, um zu einem ausgewogenen Bild zu kommen.--Cactus26 (Diskussion) 17:17, 20. Jun. 2013 (CEST)

Danke, da sind wir ja mal wieder einer Meinung. Die Enzyklopädie ist wirklich ein "Fass ohne Boden".

Ob tatsächlich immer ein Abort eintritt weiß ich nicht, im Artikel wird das nur als eine von mehreren möglichen Folgen beschrieben - was ich für ok halte. Wenn ich 'memory leaks' richtig verstanden habe UND ein Programm die Ursache dafür ist (wie dort erwähnt), dann wäre das aus meiner Sicht ebenfalls ein Fall dieser 'infinite number of things' causing runtim errors.

Zu deinem Nachtrag: Ich halte das auch für Quatsch, denn dann wäre jeder primitive Programmfehler, der beim Testen nicht bemerkt wurde (z.B. falsche Anzeige von Dezimalstellen) ein 'Laufzeitfehler'. Belastbar scheint mir das Kriterium aus dem Informatik Duden "Computer meldet Fehler".

Muss man also wieder eine aufwändige Recherche betreiben? Wer bewertet die Qualität der Quellen? Das Ergebnis wird zweifellos die Aussage sein "es gibt unterschiedliche Definitionen". Da die WP keine Wertung vornehmen will, bleibt gar nichts anderes übrig, als dies auch so zu formulieren - und den Unterschied zwischen den Definitionen möglichst klar darzustellen. --VÖRBY (Diskussion) 17:36, 20. Jun. 2013 (CEST)

Ich habe nicht das Gefühl, dass Du Memory Leak richtig einschätzt. Das bedeutet eigentlich nur, dass das Programm mehr Speicher beansprucht als eigentlich nötig. Für Programme, die nicht dauerhaft laufen, beeinträchtigt dies die Funktionalität fast nie und auch die Performance eher selten. Die Definition "Computer meldet Fehler" finde ich richtig schlecht. Sie ist offensichtlich falsch, z.B. Meldungen über ungültige Benutzerangaben sind keine Laufzeitfehler. Dass man in der WP gute von schlechten (richtige von falschen) Quellen trennen muss, ist fast überall so. Man kann nicht vor lauter Neutralität jeden Unsinn zitieren. Die Quellen muss man als Autor selbst einschätzen können, das kann einem niemand abnehmen.--Cactus26 (Diskussion) 19:24, 20. Jun. 2013 (CEST)

Kann sein, dass ich das memory leak falsch einschätze. Aber so wie beschrieben kann das zu Abbrüchen führen. Ist aber eigentlich Nebensache.

Nochmal zu "Alles außer Syntax-Fehler:" Wenn damit jeder Fehler gemeint ist, erscheint mir das schon seltsam: Ein Fehler, den eine Fachabteilung nach 3 Wochen feststellt, ist natürlich auch 'zur Laufzeit' passiert. Darin aber einen 'Laufzeitfehler' zu sehen, ist doch schräg, oder?

"Computer meldet Fehler" steht so in der Quelle, ist aber sicher nur auf das technische System und die technischen Fehler bezogen, nicht auf programmierte Fehlermeldungen im Anwenderprogramm. Lt. Deiner Quelle1: "the program instructs the computer to do something that it is either incapable or unwilling to do"

Wir haben jetzt schon wieder derart viele Disk-Aspekte, Kriterien, Argumente, Gegenargumente etc., dass ich mich frage, ob es sich lohnt, hier weiterzumachen. Jedenfalls ist dieses Diskutieren sehr mühsam.--VÖRBY (Diskussion) 19:47, 20. Jun. 2013 (CEST)

ergänzt: --VÖRBY (Diskussion) 20:29, 20. Jun. 2013 (CEST)

Lohnen würde es sich schon, den gordischen Knoten hier zu zerschlagen. Ein mühsames und undankbares Geschäft (es werden immer wieder Leute auftauchen, die es besser wissen), die Analogie zur Textdatei ist nicht zu übersehen. Ich habe mal ein wenig quergelesen. Mindestens 80% der ernstzunehmenden Quellen favorisiert die Definition i.e.S. (z.B. [8]. Aber selbst in gedruckter Form gibt es höchst merkwürdige Sichtweisen ([9], wenn man bei "Hello, World!" das "l" vergisst ist das ein Run time error). Meiner Ansicht hat die Def. i.w.S. verschiedene Nachteile:

• die damit bezeichnete Fehlermenge ist völlig heterogen (insbes. auch was ihre Schwere anbelangt)
• der Begriff ist eigentlich recht überflüssig, weil er schlicht die Restmenge einer anderen Menge ist.
• diese andere Menge wird häufig als "Synatxfehler" bezeichnet, was genau genommen nicht korrekt ist, da viele Compiler mehr als Syntaxfehler aufdecken, es müsste Compilefehler sein.

Der Begriff i.e.S. ist immer ein schwerwiegender Fehler.--Cactus26 (Diskussion) 07:32, 21. Jun. 2013 (CEST)

Nachtrag: Der heute wohl häufigste Laufzeitfehler steht gar nicht im Artikel: Eine nicht abgefangene Exception.--Cactus26 (Diskussion) 07:51, 21. Jun. 2013 (CEST)

Guten Morgen! Nur die 80%-Sicht macht mE Sinn: Da lehnt der Rechner bei der Ausführung etwas ab, was das Programm von ihm anforderte (the program instructs the computer; diese Sicht scheint mir wesentlich), genau wie das der Compiler beim Syntaxfehler tut. Die 20%-Verfechter hatten mE nicht die Restmenge zu Programmfehler im Blick, die nur technischen Beispiele zeigen das auch. Das triviale Hello-Wor(l)d-Beispiel scheint da eine Ausnahme zu sein - die aber durch das "run-tim-errors are more troublesome" auch gleich wieder relativiert wird. Deine Mengenargumentation halte ich für zutreffend und ok.

"Immer schwerwiegender Fehler" wäre eine Kompromissformulierung, die aber wieder Raum für Spekulationen lässt. 'Mit Abbruch' wäre klar: Computer kann etwas nicht tun - und reagiert. Dann wäre aber zB eine Situation KEIN LZF, bei der jemand (ein Operator, das Nachfolgeprogramm ...) beim oder nach dem Lauf des Programms (ohne Abbruch!) feststellt, dass keine Ausgabedaten erstellt wurden. Gründe könnten vielfältig sein - JCL-Fehler, Pgm-Fehler. Hier hätten wir also ein wichtiges Kriterium.

"Besser wissen:" Diesbezüglich sollte man auch die "i.w.S"-Variante erwähnen und belegen, aber die Unterschiede klar abgrenzen/beschreiben.

Die Exception sehe ich anders als du: Das ist lediglich die mögliche Fehlerbehandlung. Der Fehler (eigentlich die 'Fehlerwirkung') ist dann schon eingetreten und es macht keinen Unterschied, ob das Betriebssystem abbricht oder (aus demselben Grund, nur mit einer anderen Meldung) das Anwenderprogramm. Ausnahme könnte sein, wenn das E-Handling den Fehler tatsächlich korrigieren kann. Das ist aber für unsere Diskussion nur eine Nebensache. --VÖRBY (Diskussion) 10:15, 21. Jun. 2013 (CEST)

Die Def. i.w.S. muss man erwähnen, sie ist in der Literatur sogar deutlich etablierter als die ugs. Sicht bei der Textdatei. Meine obige Liste kann eher als Vergleich beider Sichten dienen und ist eine Rechtfertigung, warum es sich nicht lohnt, auf diese Def. weiter einzugehen. Aber auch die Def. i.e.S. hat so ihre Abgrenzungsprobleme. Insbesondere das mit der Exception schätzt Du falsch ein, ich vermute, Du hast bisher wenig Erfahrung mit diesem Konzept.--Cactus26 (Diskussion) 10:43, 21. Jun. 2013 (CEST)

Ich habe mir die Sache nochmal überlegt und auch in der Historie nachgesehen. Die Formulierung "Gegensatz" hatte ich selbst in [10] als Überarbeitung des alten Textes eingebracht. Insofern habe ich selbst das Problem mit dem 'Komplement' geschaffen. Ich habe das heute wieder korrigiert. Die Motivation für den Hinweis auf Syntaxfehler (als andere Fehlerart, andere Programmfehler aber nicht erwähnend) mag aus der en:WP stammen.
Allerdings ändert das nichts an der Tatsache, dass es unterschiedliche Definitionen gibt.
Ein weiteres Problem war die Aussage, dass ein LZF ein Programmfehler sei; dies ist (und war schon vor meiner Änderung) falsch: Ein PF kann zu einem LZF führen, woraus man nicht ableiten kann, dass ein LZF ein PF ist. Auch die en:WP nennt 'Programmfehler' nicht.
Die bedingt falsche Sicht 'Programmfehler' ist möglicherweise auch die Ursache für Diskrepanzen hier in der Diskussion: Begriffsbestimmend ist nicht primär 'das Programm', sondern die 'Ausführung eines beliebigen Programms' - während der ein LZF aus vielen Gründen auftreten kann. Aus dieser unterschiedlichen Perspektive (Programm : Ausführung) mag auch das Löschen des LZF-Beispiels 'Drucker nicht verfügbar' resultieren: Er tritt zweifellos zur Laufzeit eines Programms auf, nämlich z.B. des Spoolers. --VÖRBY (Diskussion) 15:50, 21. Jun. 2013 (CEST)

Kurz zur Formulierung "Gegensatz":

Ich fand diese Formulierung passend, da es (wie ich versucht habe herauszuarbeiten) einerseits Fehler gibt, die vor der Ausführung bzw. Laufzeit geschehen und dann eben die LZF die währenddessen auftreten. Hätte ich nicht gesehen, dass du, VÖRBY, diese Formulierung in deinem vorherigen Edit herausgenommen hast, hätte ich sie stattdessen eingesetzt. --Plankton314 (Diskussion) 16:51, 21. Jun. 2013 (CEST)

So wie das beschrieben ist, schien 'Gegensatz' ja auch passend. Aber:

• wenn man 'Gegensatz' schreibt, sollte bekannt sein, was die 'Gesamtmenge' ist. Und das war im bisherigen Text der Begriff 'Programmfehler'.
• Wenn als Gegensatz nur 'Compilerfehler' beschrieben sind, entsteht sofort die Frage "Was ist mit den 'normalen' Programmfehlern?" Dies war der ursprüngliche und eigentliche Diskussionspunkt hier.

Ohne 'Gegensatz' kommt diese Komplement-Konstruktion wenigstens nicht so deutlich zum Ausdruck. Rein logisch fehlt diese Aussage trotzdem, entweder als Abgrenzung oder als alternative Definition, dass 'nach anderen Quellen' alle Programmfehler LZF sind - wenn sie zur Laufzeit auftreten. Nach dem Rest des Einleitungstextes könnte man diese 'kleine Logiklücke' aber auch lassen; es ist ja nichts Falsches gesagt. Weiß nicht, ob und wer nun noch was tut. --VÖRBY (Diskussion) 19:03, 21. Jun. 2013 (CEST)

Ich habe mich ehrlich gesagt, mit dem Thema und seinen Definitionen gerade nicht eingearbeitet, aber grundsätzlich sehe ich hier keinen Widerspruch.

Die Kategorisierung eines Fehlers als "zur Laufzeit" oder nicht erhebt doch keinen Anspruch auf Exklusivität. Laufzeitfehler können genauso wiederum Teil einer anderen Fehlerkategorie sein, es handelt sich nicht um eine exklusive Fehlerart.

'Gegensatz' bedeutet: Dieser Fehler und der als Gegensatz beschriebene bilden zusammen eine Gesamtheit, außerhalb der es nichts weiteres gibt. Das ist mit der neuen Formulierung 'entschärft'.--VÖRBY (Diskussion) 14:16, 22. Jun. 2013 (CEST)

"Normale" Programmfehler fallen, je nach dem wo sie auftreten, eben mal in die LZF-Kat und mal nicht. ZB. würde ich einen Syntaxfehler bei einer kompilierten Sprache nicht als Laufzeitfehler bezeichnen, weil der Compiler daraufhin nichts produziert, was ausgeführt werden könnte. Wenn jedoch ein Skript mitten in der Ausführung abbricht, weil der Interpreter einen Syntaxfehler entdeckt, dann ist das eben ein LZF. Gleicher Fehler, nur je nach dem eben LZF oder nicht.

Nochmal: LZF sind keine Programmfehler, sondern sie können die Folge davon sein.

Syntax-Compiler-fehler =/= LZF: So steht das auch im Text. Beim Interpretieren fällt die Syntaxprüfung und die Ausführung zwar zeitlich zusammen. Wenn aber ein Syntaxfehler auftritt, sollte das eine andere (= vorgesehene!) Reaktion nach sich ziehen (= kein Laufzeitfehler i.e.S.) als wenn dem Prozessor eine Division durch Null vorgegeben wird. Hier sollte die Definition nach Quelle-1 von Cactus26 ziehen: LZF = "Der 'Computer' (= Prozessor) KANN die vorgegebene Instruktion nicht ausführen".

Unsere wesentliche Frage war aber: Gilt ein normaler Pgm-Fehler ohne Abbruch als LZF? --VÖRBY (Diskussion) 14:16, 22. Jun. 2013 (CEST)

Ich habe diese Frage gesehen und aus dem Bauch heraus würde ich das Bejahen. --Plankton314 (Diskussion) 14:38, 22. Jun. 2013 (CEST)

Wie ihr schon festgestellt habt, gibt es unzählige Möglichkeiten einen LZF zu definieren. Wenn hier in der Literatur keine einhellige Meinung herrscht, sollte man das auch so festhalten. Allgemein gilt sicherlich, dass er während der Ausführung des Programms eintritt. Wenn man mehr dazu nicht sicher sagen kann, gibt es einfach nicht mehr zu definieren. Es kann nur gesagt werden, dass eine exakte Definition (darüber hinaus) nicht gegeben ist.

--Plankton314 (Diskussion) 13:18, 22. Jun. 2013 (CEST)

Wie schon festgestellt wurde, gibt es aber präzisere Definitionen. Meine Meinung ist, diese Unterschiede zu beschreiben - anstatt nur zu sagen, es gäbe keine exakte Definition.--VÖRBY (Diskussion) 14:16, 22. Jun. 2013 (CEST)

In diesem Sinn hatte ich es eigentlich auch gemeint (also natürlich nur bis zu einem gewissen Grad, ich denke, wir sind uns einig, dass nicht jede auffindbare Definition abgegrenzt werden muss). --Plankton314 (Diskussion) 14:38, 22. Jun. 2013 (CEST)

Diese neue Formulierung in der Einleitung die sich auf "schwerwiegende Syntaxfehler" beruft, finde ich ziemlich unglücklich. Es gibt einen Haufen Gründe, warum ein Programm erst garnicht bis zur Laufzeit kommt und dabei dann ausgerechnet Syntaxfehler anzuführen wird der Sache nicht gerecht. Grundsätzlich sind es mal alle Fehler, die den Compiler/Linker/usw. daran hindern, ausführbaren Code zu generieren. Das kann in einem "dummen" Fall auch ein volles Laufwerk sein.

Außerdem ist es irreführend, die Formulierung "vor der Ausführung" durch "während der Entwicklung" zu ersetzen. Wie auch zuvor gibt es hier ein Vielzahl an Möglichkeiten nach der Entwicklung und vor der Laufzeit, die eine Ausführung verhindern können. Ein Fehler, der nach der Entwicklung aber noch vor der Ausführung auftreten könnte, wäre zB. dass kein freier Speicher mehr zur Verfügung steht. Definitionsgemäß kann ein Laufzeitfehler erst zur Laufzeit auftreten und nicht davor. Was ist deiner Meinung nach an der Formulierung "vor der Ausführung" missverständlich? --Plankton314 (Diskussion) 13:12, 22. Jun. 2013 (CEST)

Hallo Plankton314, "Vor der Ausführung" grenzt den Fehlerzeitpunkt m.E. zu wenig von der Ausführung ab bzw. positioniert diese Zeitangabe nicht eng genug bei der Softwareentwicklung. Um diesen Zeitpunkt geht es aber im zweiten Absatz - der eigentlich gar nicht nötig wäre, weil der erste Absatz schon aussagt, ein LZF sei ein Fehler "bei der Ausführung" - die bei Compilerfehlern nicht möglich ist.

Einen weiteren Zeitraum ins Spiel zu bringen, halte ich für nicht angebracht: Wenn zur Ausführung kein freier Speicher verfügbar ist, dann gehört das zur Ausführung. Was zwischen der SW-Entwicklung (Compile, Installation) und einer beliebigen Ausführung geschieht (Extrembeispiel "Rechenzentrum brennt ab"), hat nichts mit Laufzeitfehler zu tun.

Da fällt mir noch was auf: Das Lemma ist der Kategorie 'Programmfehler' zugeordnet. Könnte es evtl. sein, dass 'man' hier einfach den Begriff 'Programmfehler' (tatsächlich Fehler im Pgm) danach klassifizieren wollte, wann in welchem Software-Lebenszyklus er auftritt? Dann wäre die ganze Diskussion um die technische Interpretation (Datei oder Server nicht verfügbar ...) überflüssig bzw. in anderem Licht zu sehen; denn das sind keine Programmfehler. Meine Aussage zu "Ist vs. führt" würde auch nicht zutreffen, sondern wir hätten wirklich mehrere unterschiedliche Begriffe/Definitionen. Grüße von --VÖRBY (Diskussion) 09:13, 23. Jun. 2013 (CEST)

Unterschiedliche Definitionen

Bei der Suche nach unterschiedlichen Definitionen fielen mir Sachverhalte auf, die ich zusätzlich in den Artikel eingestellt habe. Die Frage nach möglicherweise unterschiedlichen Definitionen blieb dabei jedoch offen. Aus meiner Sicht gibt es 2 oder 3 mögliche Definitionen:

• a) technischer Fehler mit Abruch beim Ausführen eines beliebigen Programms;

egal aus welchem Grund, egal in welcher Umgebung, egal zu welchem Zeitpunkt:

Der Computer kann das "Instruierte" nicht ausführen, alle Arten von Software betreffend

schließt Compilerfehlermeldung de facto aus.

• b) Klassifizierung eines Programmfehlers - nach dem Zeitpunkt des Auftretens im SW-Lebenszyklus

damit ausdrücklich Fehler (nach a beim Testen) ausgeschlossen; eher selten zu finden

• c) Jegliche Art von Fehler bei der Ausführung von Programmen

auch Fehler ohne Abbruch, Logikfehler, Systemumgebung egal, auch im Test

--VÖRBY (Diskussion) 13:07, 23. Jun. 2013 (CEST)

Ich schlage vor, in der Einleitung, in einem eigenen Kapitel "Unterschiedliche Definitionen" (oder am Ende der Einleitung) folgende Ergänzung vorzunehmen:

Der Begriff 'Laufzeitfehler' wird in der Literatur im Detail unterschiedlich definiert. Als Gemeinsamkeit gilt, dass er „während der Ausführung“ von Programmen auftritt und dass vom Compiler etc. festgestellte Fehler keine Laufzeitfehler sind. Unterschiede oder unpräzise Formulierungen (oder Diskrepanzen zwischen Definition und Beispielen) lassen sich in folgenden Kriterien finden, zum Teil in Kombination oder sogar innerhalb derselben Fundstelle:

• Fehlerquelle:
  • Als Laufzeitfehler gelten nur „Programmfehler“ (bei ,, ). Nach dieser Sichtweise sind Laufzeitfehler immer Programmfehler und bilden eine der möglichen Fehlerkategorien.
    
  • Beliebige Ursachen können zum Laufzeitfehler führen (bei , „or as a result of external effects“).
• Fehlerwirkung:
  • Der Laufzeitfehler führt immer zum Abbruch (nach )
    
  • Auch logische Fehler (die keinen Abbruch zur Folge haben, aber im Produktivbetrieb entstehen und meist erst mit Verzögerung bemerkt werden) gelten als Laufzeitfehler. (So bei eine falsche Textkonstante)
• Systemumgebung/Fehlerzeitpunkt:
  • Laufzeitfehler treten nur im Produktivbetrieb auf (nach ; „... nicht während der Programmentwicklung erkannt“)
    
  • Sie können in allen Systemumgebungen inkl. Testbetrieb auftreten (dies wird in den meisten Definitionen nicht explizit genannt).

oder Kurzform statt Aufzählungsliste: (würde das evtl. genügen?)
ob als Laufzeitfehler nur „Programmfehler“ gelten oder ob sie beliebige Ursachen haben können; ob bei Laufzeitfehlern immer ein Abbruch stattfindet oder ob auch logische Fehler ohne Abbruch Laufzeitfehler sein können; ob als Laufzeitfehler nur Fehler im Produktivbetrieb gelten oder ob jeder entsprechende Fehler während eine Ausführung (z. B. auch beim Testen) als Laufzeitfehler gilt.

(==Weblinks==)

• Deutsches Softwareentwickler-Wiki [11]

aktualisiert und mit Belegen versehen: --VÖRBY (Diskussion) 10:09, 26. Jun. 2013 (CEST)
alternativ eine Kurzform (ohne Belege): --VÖRBY (Diskussion) 16:20, 26. Jun. 2013 (CEST)

Ich habe einen Abschnitt 'Abweichende Bedeutungen' in der Einleitung ergänzt und die gefundenen Belege eingefügt. Als zentrale Aussage gilt 'während der Laufzeit aufgetreten', während die im Detail unterschiedlichen weiteren Kriterien ebenfalls beschrieben sind. Damit zeigt der Artikel die 'gängigen' Kriterien (mit Belegen), aber keine eindeutige Definition. Ist halt so. --VÖRBY (Diskussion) 10:08, 3. Jul. 2013 (CEST)