AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Programmieren allgemein Fehler vorbeugen vs Code aufblähen
Thema durchsuchen
Ansicht
Themen-Optionen

Fehler vorbeugen vs Code aufblähen

Ein Thema von .chicken · begonnen am 24. Mär 2008 · letzter Beitrag vom 25. Mär 2008
Antwort Antwort
shmia

Registriert seit: 2. Mär 2004
5.508 Beiträge
 
Delphi 5 Professional
 
#1

Re: Fehler vorbeugen vs Code aufblähen

  Alt 25. Mär 2008, 11:10
Es muss ein 3 stufiges Sicherheitsnetz geben:

1.) schon bei den Controls sollte man ungültige Benutzereingaben abfangen und gar nicht erst zulassen
Beispiel: verwendet man einen TDateTimePicker, kann man gar kein ungültiges Datum eingeben; im Gegensatz zu einem TEdit
Wenn man ein Editfeld hat, dass nur eine Zahl aufnehmen soll, kann man z.B. nur Ziffern als Eingabe zulassen oder TMaskEdit verwenden.

2.) Exceptions werden verwendet für alle Fehler, mit denen im Programmablauf gerechnet wird.
Dateien, die nicht geöffnet werden können. Datenbankabfragen, die schiefgehen können, ungültige/fehlende Eingabewerte,
u.s.w.
Dabei sollte man darauf achten, eine möglichst genaue Fehlermeldung zu produzieren.
Von der VCL werden manchmal sehr allgemeine Exceptions generiert (z.B. '' ist kein gültiger Integerwert | ungültige Variantumwandlung)
Diese allgemeinen Exceptions taugen natürlich gar nicht zur Fehlereingrenzung.
Deshalb sollte man regelmäsig Exception abfangen, mit Informationen anreichern und neu auslösen:
Delphi-Quellcode:
// Beispiel
try
  BerechneSteuer(IdKunde);
except
  on E: Exception do
  begin
    // eine informative Meldungen erzeugen
    E.Message := Format('Fehler bei der Steuerberechnung des Kunden %d'#13#10, [IdKunde]) +
      E.Message; // WICHTIG: die orginale Message anhängen.
    raise; // Exception neu auslösen
  end;
end;
3.) der letzte Rettungsanker sind Assertions.
Sie werden verwendet, ob um das Programm vor eigenen Programmierfehlern zu schützen.
Wenn man z.B. eine Funktion hat, die ein Objekt entgegennimmt, sollte man mit Assert sicherstellen,
dass nicht durch einen Programmierfehler ein nil-Zeiger übergeben wird.
Man fängt hier also Fehler ab, die eigentlich niemals auftreten dürften.
Es gilt die Devise: Vertrauen ist gut, Kontrolle ist besser.

Jedes Programm sollte eine Testphase durchlaufen.
Sobald eine Assertion auftritt, muss der Programmierer alles stehen und liegen lassen und die Ursache herausfinden!!

Tritt eine Assertion beim Test oder beim Endbenutzer auf, gibt es zwei Möglichkeiten:
a.) das Programm hat einen Bug
b.) der Programmierer hat eine Assertion verwendet, wo eigentlich eine Exception nötig gewesen wäre

In beiden Fällen ist eine Programmänderung notwendig.
Wenn das Programm gut ausgereift ist, dann darf man die Assertions in den Projektoptionen abschalten
und erhält das ein etwas schnelleres und kleineres Programm.
Andreas
  Mit Zitat antworten Zitat
Antwort Antwort


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 14:17 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz