Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Arno Welzel Newsgroups: de.alt.folklore.computer Subject: Re: Nostalgiecomputer Date: Sun, 30 Apr 2023 20:12:28 +0200 Lines: 25 Message-ID: References: <87ildf7bl3.fsf@usenet.ankman.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Trace: individual.net NRJSjkiPowbla+wvpH4X3gZip7Onlha1wxhLbJKNgW6LjxV7ZB Cancel-Lock: sha1:XzTpE8n02JDh2vJ6VyFKa1QzLWo= Content-Language: de-DE In-Reply-To: Xref: csiph.com de.alt.folklore.computer:39342 Peter J. Holzer, 2023-04-30 17:32: [...] > Unter Umständen ist es auch hilfreich, das Fault-Error-Failure Modell > von Laprie im Kopf zu haben: Ein Fault ist ein "böses" Ereignis: Ein > Hardware-Fehler, ein falscher Messwert, eine falsche Eingabe durch den > Benutzer. Das kann (muss aber nicht) zu einem Error führen, einem > fehlerhaften Zustand des Systems. Das wiederum kann zu einem Failure > führen, einem Versagen (Absturz, falsches Ergebnis, ...). Ein ein > Failure eines (Sub-)Systems kann dann wieder ein Fault eines anderen > (Sub-)Systems sein. Direkt beobachtbar sind i.A. nur Failures, aber IMHO > bedeutet jeder Error, dass das System nicht korrekt funktioniert (außer > es gibt explizite Mechanismen (z.B. Redundanz) um den Error zu beheben). Generell ist es hilfreich, bei *jeder* Aktion die erwarteten Ausgangsbedingungen zu prüfen. Also nie davon ausgehen, dass irgendein Dienst per se verfügbar ist oder dass ein API immer nur die erwarteten Daten liefert oder die erwartete Form oder dass ein Kommando immer aufrufbar sein wird. -- Arno Welzel https://arnowelzel.de