Softwarekrise (was: Re: [linux-l] Slightly off topic: Jagd auf Spam)

Steffen Dettmer steffen at dett.de
Sa Nov 1 15:07:49 CET 2003


* Jan Krueger wrote on Fri, Oct 31, 2003 at 21:39 +0100:
> Um die Gedanken auszusprechen:
> 
> Wir gehen also davon aus, dass das alles nicht so richtig
> funktioniert und nutzen folglich Programmiersprachen die uns im
> Fehlerfall unterstützen, also sowohl den Programmierer als auch
> den Wuser.

Ich sag mal: "Fehlerbehandlung anstatt einfacher Fehlerreaktion".

> Was mir aber im Moment noch völlig unklar ist, ist wie man das
> dem Nutzer nahe bringt, d.h. Nutzer schreibt einen Text in
> Textverarbeitung, Nutzer ruft irgendeinen Menüpunkt auf,
> Textverarbeitung möchte sterben -> Interrupt, 

"möchte sterben" ist schon zu weit. "Funktion führt zu keinem
positiven Ergebnis".

> Möglichkeit 1: Interrupthandler fragt Nutzer was er wollte,
> fragt Anwendung was sie wollte, diff, Code/Context wird
> korrigiert und weiter geht es.

na fein :) Die Daten sind schon inkonsistent, der User
überfordert, denke ich.

> Möglichkeit 2: Interrupthandler präsentiert Nutzer alternative
> Möglichkeiten, Nutzer wählt eine aus, Code/Context wird
> korrigiert und weiter geht es.
> 
> Korrigieren kann auch heißen, dass zb. der Menüpunkt entfernt wird.

Genau!

Ich könnte mir das so vorstellen: Die Funktion bekommt den Text
in einer Art Transaktion mit Rollback-Möglichkeit. Ne Art
Super-Komfort-Auto-Save. Klappts nicht, also Rollback möglich.
Schon mal was. Menüpunkt kann auch drin bleiben. Jedenfalls
könnte der Fehler wie folgt behandelt werden:

  Die Funktion "Grafik einfügen" konnte nicht erfolgreich
  ausgeführt werden. Die Fehlerbeschreibung wurde ins Logfile
  geschrieben. Die Kurzmeldung der Komponente war:
  
  SCM GraphicsInsert 1.2.3 (Release-Candidate_2003_10_31)
  Read error while decompressing (decomp.cc:471)
  System error (I/O error) (readdata.cc:133)
  
  Ihr Text wurde nicht verändert. Sie können das Logfile und diese
  Datei an die Entwicklung senden, um zukünftige Versionen zu
  verbessern.

In dem Fall fehlt der Komponete das Abfangen eines Lesefehlers,
sowas kommt öfter mal vor (oder die Folgenbehandlung ist falsch).

> > > . Mach mal was grosses wie Word, aber
> > > ohne Bugs. Wird nicht trivial. Der Schlüssel müßte IMHO dadrin
> > > liegen, die "1 Bug je 500 Zeilen" auf "1 Bug 2000 Zeilen"
> > > reduzieren zu können. Vielleicht wäre es auch mal an der Zeit,
> > > sich "redundante" Programmiertechniken anzugucken
> > 
> > gute Idee, werde gleich mal auf die Suche gehen...
> > 
> ...und nix so richtig finden was da weiter hilft. Daher festigt
> sich meine Überzeugung, dass die Nutzung höherer
> Programmiersprachen wesentlich zu Nutzbarmachung und Sicherheit
> und Stabilität von Rechnersystem beitragen wird müssen.

Ja, es sind wichtige 10% des Themas, ja. Aber Sprachen lösen
keine Design und nichtmal Implementierungsprobleme, sie
unterstützen nur, daß man das richtige etwas einfacher machen
kann - wichtig, klar, aber nicht alles. Notwendig, aber nicht
hinreichend.

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.




Mehr Informationen über die Mailingliste linux-l