mikrocontroller.net

Forum: PC-Programmierung Wie Programm beenden?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Paul Schokemöhl (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe angefangen in C zu programmieren. Auf einem Linux PC mit gcc. 
Ich habe jetzt Funktionen, die Funktionen usw. aufrufen. Wenn ich jetzt 
in irgendeiner aufgerufenen Funktion z.B. eine Datei öffnen will, aber 
der Rückgabewert ist eof und ich möchte das ganze Programm einfach 
printf("Fehlermeldung, dies und das, bla und Blub"); und Abbruch, wie 
mache ich das, ist das schlau?

von Dirk K. (d-k)


Bewertung
0 lesenswert
nicht lesenswert
Paul Schokemöhl schrieb:
> wie
> mache ich das,
exit(-1);

> ist das schlau?

Nein.

: Bearbeitet durch User
von Paul Schokemöhl (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Dirk K. schrieb:
> Paul Schokemöhl schrieb:
> wie
> mache ich das,
>
> exit(-1);
>
> ist das schlau?
>
> Nein.

Also nicht schlau. Wie mache ich es, das es schlau ist?

von MaWin (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
Ganz schlecht ist:

main(...) {

...
ENDE :
printf(...);
}

int foo(...) {
...
goto ENDE;   // Abbruch
}

von Tim T. (tim_taylor) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Paul Schokemöhl schrieb:
> ist das schlau?

Kommt drauf an, wenn dein Programm noch sinnvoll ohne die Datei 
weiterarbeiten kann dann nicht, wenn es ohne die Datei zu öffnen 
praktisch nichts brauchbares mehr machen kann, dann schon.

von Hmmm (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Beispielsweise aus main() Deine File-Einlese-Funktion aufrufen und den 
Rückgabewert davon auswerten.

von Tim T. (tim_taylor) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Du rufst einfach in Abhängigkeit vom Rückgabewert der entsprechenden 
Funktion eine Aufräumfunktion auf, die im einfachsten Fall nur den Grund 
auf dem jeweiligen Device ausgibt und anschließend das Programm mit 
einem entsprechenden Rückgabewert beendet. In komplexeren Fällen führt 
die Funktion dann noch Aufräumarbeiten durch.

von Daniel A. (daniel-a)


Bewertung
0 lesenswert
nicht lesenswert
Paul Schokemöhl schrieb:
> Wenn ich jetzt
> in irgendeiner aufgerufenen Funktion z.B. eine Datei öffnen will, aber
> der Rückgabewert ist eof

EOF = End Of File

fopen liefert bei Fehler normalerweise 0 zurück, open und andere posix 
Funktionen meistens -1. Jedenfalls nicht EOF.

Paul Schokemöhl schrieb:
> ich möchte das ganze Programm einfach
> printf("Fehlermeldung, dies und das, bla und Blub"); und Abbruch, wie
> mache ich das, ist das schlau?

Fehlermeldungen würd ich nach stderr (standard error) schreiben:
fprintf(stderr, "Fehler!\n");

Oder ins system log:
https://linux.die.net/man/3/syslog

Ich schreibe manchmal auch eine eigene logging Funktion, die dann nach 
stderr oder syslog schreibt.

Beenden kann man es mit mehreren Funktionen, unter anderem: abort exit 
_Exit

Diese tun leicht verschiedene Dinge.

Frameworks, wie z.B. gtk, haben oft nochmal eigene logging Funktionen 
usw., normalerweise mit der Möglichkeit eine eigene logging handler 
funktion zu registrieren.

von Rolf M. (rmagnus)


Bewertung
1 lesenswert
nicht lesenswert
Dirk K. schrieb:
> Paul Schokemöhl schrieb:
>> wie
>> mache ich das,
>
> exit(-1)

Warum gerade -1? Was unterstützt und sinnvoll zum Aufrufer übergeben 
wird, ist systemabhängig. Ich würde positive Werte im Bereich 0 bis 127 
empfehlen, das sollte auf den meisten Systemen gehen.
Wenn man sich auf ISO C beschränken will, das überall funktionieren 
sollte, muss man sich auf EXIT_FAILURE und EXIT_SUCCESS beschränken.

>> ist das schlau?
>
> Nein.

Sagen wir mal so: Für sehr einfache Programme kann man das schon mal 
machen, aber meistens ist es keine gute Idee. Es ist besser, das Problem 
an den Aufrufer zurückzumelden, damit der dann geeignet reagieren kann 
statt einfach das Programm "eigenmächtig" zu beenden.
Man stelle sich vor, das wird mal ein GUI-Programm, und die Routine, die 
versucht, eine Datei zu öffnen, schießt gleich das ganze Programm ab, 
nur weil sie die Datei nicht findet.
Man muss zusätzlich auch bedenken, dass alle Ressourcen, die ggf. in 
anderen Programmteilen genutzt werden, nicht sauber freigegeben werden, 
es sei denn, sie definieren dafür extra einen atexit-Handler.

Daniel A. schrieb:
> Fehlermeldungen würd ich nach stderr (standard error)
> schreiben:fprintf(stderr, "Fehler!\n");
> Oder ins system log:
> https://linux.die.net/man/3/syslog

Es ist für einen Programmieranfänger eher nicht sinnvoll, wenn seine 
ersten Versuche ihre Outputs ins syslog schreiben.

: Bearbeitet durch User
von foobar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
    #include <stdlib.h>
    #include <string.h>
    ...
    FILE *fp;
    ...
    fp = fopen(filename, "r");
    if (fp == NULL)
    {
        fprintf(stderr, "can't open '%s': %s\n", filename, strerror(errno));
        exit(EXIT_FAILURE);
    }
    ...

> Ist das schlau?

Ist quick'n'dirty.  Du gibst so dem Aufrufer keine Chance, den Fehler 
irgendwie zu behandeln - eine untergeordnete Funktion entscheidet, ob 
das Programm weiterläuft oder nicht.

von Programmierer (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Oder direkt eine Sprache verwenden, welche ein systematisches 
Fehlermanagement in Form von Exceptions bietet, sodass man sich das 
Herumhantieren mit Rückgabewerten spart. z.B. C++:
#include <stdexcept>
#include <stdio.h>

void foo () {
  FILE* f = fopen ("test.txt", "r");
  if (!f)
    throw std::runtime_error ("Datei konnte nicht geöffnet werden");
  
  puts ("Mach was mit der Datei");
  fclose (f);
}

void bar () {
  puts ("bar(). Mache was...");
  foo ();
  puts ("bar(). Mache nochwas mehr...");
}

int main () {
  try {
    puts ("main(). Mache was...");
    bar ();
    puts ("main(). Mache nochwas mehr...");
    return 0;
  } catch (const std::exception& e) {
    fprintf (stderr, "Fehler: %s\n", e.what ());
    return 1;
  }
}

Natürlich wäre es besser hier direkt die C++-Klassen wie std::ifstream 
zu nutzen statt das C-I/O über fopen() & Co. Im Idealfall hat man genau 
eine Stelle mit Fehlerbehandlung, direkt in der main(), und der 
restliche Code sieht so aus als gäbe es keine Fehler, indem man den 
Compiler das Rückwärts-Abwickeln erledigen lässt.

von Daniel A. (daniel-a)


Bewertung
0 lesenswert
nicht lesenswert
Programmierer schrieb:
> Oder direkt eine Sprache verwenden, welche ein systematisches
> Fehlermanagement in Form von Exceptions bietet

Dafür gibt es für C auch Libraries:
https://github.com/guillermocalvo/exceptions4c

von Sebastian S. (amateur)


Bewertung
0 lesenswert
nicht lesenswert
@Paul Schokemöhl
Was Du willst ist eine sehr unfreundliche Art mit dem Benutzer 
umzugehen.

"Du, Du, böser!" und Abbruch ist würglich unfreundlich.

DU bist es, der den Programmfluss kontrolliert.
Eine einfache Meldung: "Dateiende erreicht", von mir aus auch auf 
Auswärts, mit anschließender Abfrage: "Watt nu?" wäre zumindest höflich.

Also komm mal runter von Deinem hohen Ross!

Übrigens: In der heutigen Zeit kann es schwierig werden, die 
Abschlussmeldung einer Konsolenanwendung zu lesen.

von c-hater (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Programmierer schrieb:

> Natürlich wäre es besser hier direkt die C++-Klassen wie std::ifstream
> zu nutzen statt das C-I/O über fopen() & Co. Im Idealfall hat man genau
> eine Stelle mit Fehlerbehandlung, direkt in der main(), und der
> restliche Code sieht so aus als gäbe es keine Fehler, indem man den
> Compiler das Rückwärts-Abwickeln erledigen lässt.

Ja, Exceptions erleichtern einiges. Aber: viele Programmierer benutzen 
sie falsch, vergessen insbesondere, nach oben die eigentliche Ursache 
zurückzugeben, so dass am Ende für den Benutzer eine völlig nutzlose 
Fehlermeldung rauskommt, die ihm keinerlei Anhaltspunkt mehr dazu 
liefert, was eigentlich das Problem war.

Der Extremfall, gerade beim Zugriff auf Dateien, sind da wohl die 
Winzigweich-Programmierer. Im Zweifel wird immer irgendwelcher Bullshit 
mit fehlenden Rechten gemeldet. Wohl weil mal irgensoein Blinder Wichser 
festgestellt hat, dass die meisten Fehler beim Dateizugriff genau darauf 
zurückgehen. Ja, das wird vermutlich sogar stimmen, aber leitet den User 
völlig in die Irre, wenn's mal nicht daran liegt...

von Programmierer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
c-hater schrieb:
> Ja, Exceptions erleichtern einiges. Aber: viele Programmierer benutzen
> sie falsch,

Ja das stimmt leider.

c-hater schrieb:
> vergessen insbesondere, nach oben die eigentliche Ursache
> zurückzugeben,

Viel schlimmer ist das wilde Mischen mit Rückgabecodes und Mengen an 
try-catch-Blöcken; im Idealfall gibt es davon nur sehr wenige. z.B. nur 
einen in der main() bei einfachen Konsolen-Programmen, oder einen pro 
Menüpunkt in einer GUI-Anwendung, welcher dann eine Fehlermeldung 
ausgibt. Leider wird korrektes Exception-Handing bzw. allgemein 
Fehler-Behandlung in vielen Büchern nicht gut erklärt, ist aber IMO 
ziemlich essentiell. In C++ ist das ja auch eng mit RAII (bzw. OOP) 
verknüpft. Das lässt sich hier auch nicht mal eben schnell in einem 
Beitrag erläutern...

c-hater schrieb:
> so dass am Ende für den Benutzer eine völlig nutzlose
> Fehlermeldung rauskommt, die ihm keinerlei Anhaltspunkt mehr dazu
> liefert, was eigentlich das Problem war.

In Java sind dafür Chained Exceptions beliebt; man packt z.B. die 
FileNotFoundException in eine eigene Exception namens 
LogFileNotFoundException sodass sich dann ein strukturierter Backtrace 
ergibt. Leider wird das dann bei der Ausgabe häufig ein ziemlicher 
Datenwust.

c-hater schrieb:
> m Zweifel wird immer irgendwelcher Bullshit
> mit fehlenden Rechten gemeldet.

Das kann Android auch! Da ist's immer "Permission Denied". Ob jetzt die 
DAC-Rechte oder die SELinux-Konfiguration (und welche der tausenden 
dafür zuständigen Zeilen) oder die diversen Prozess-Capabilities schuld 
sind darf man erraten.

von c-hater (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Programmierer schrieb:

> In Java sind dafür Chained Exceptions beliebt; man packt z.B. die
> FileNotFoundException in eine eigene Exception namens
> LogFileNotFoundException sodass sich dann ein strukturierter Backtrace
> ergibt. Leider wird das dann bei der Ausgabe häufig ein ziemlicher
> Datenwust.

So what? Lieber einen Datenwust von einer Fehlermeldung, der aber 
immerhin einen Anhaltspunkt für die Wurzel dieses Wusts gibt, als eine 
"irgendwas ist schief gegangen"-Summary, ggf. noch garniert mit einem 
default, der im konkreten Fall möglicherweise garnicht zutrifft. Was ist 
wohl nützlicher?

Übrigens sind diese Chains natürlich prinzipiell in jeder Sprache 
möglich, die nested Exceptions erlaubt, nicht nur in Java.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.