abort

Bricht den aktuellen Prozess ab und gibt einen Fehlercode zurück.

Hinweis

Verwenden Sie diese Methode nicht, um eine Microsoft Store-App oder Universelle Windows-Plattform (UWP)-App herunterzufahren, mit Ausnahme von Test- oder Debuggingszenarien. Programmgesteuerte oder UI-Methoden zum Schließen einer Store-App sind gemäß den Microsoft Store-Richtlinien nicht zulässig. Weitere Informationen finden Sie im Lebenszyklus der UWP-App.

Syntax

void abort( void );

Rückgabewert

abort gibt die Steuerung nicht an den aufrufenden Prozess zurück. Standardmäßig sucht es nach einem Abbruchsignalhandler und löst SIGABRT aus, sofern vorhanden. Anschließend beendet abort den aktuellen Prozess und gibt den Exitcode an den übergeordneten Prozess zurück.

Hinweise

Microsoft-spezifisch

Standardmäßig zeigt die abort-Routine eine Fehlermeldung an, bevor SIGABRT ausgelöst wird, wenn eine App mit der Debuglaufzeitbibliothek erstellt wird. Bei Konsolen-Apps, die im Konsolenmodus ausgeführt werden, wird die Meldung an STDERR gesendet. Bei Windows-Desktop-Apps und Konsolen-Apps, die im Fenstermodus ausgeführt werden, wird die Meldung in einem Meldungsfeld angezeigt. Um die Nachricht zu unterdrücken, verwenden Sie _set_abort_behavior diese, um die _WRITE_ABORT_MSG Kennzeichnung zu löschen. Die Meldung, die angezeigt wird, hängt von der Version der verwendeten Laufzeitumgebung ab. Für Anwendungen, die mit den neuesten Versionen von Visual C++ erstellt wurden, sieht die Meldung wie folgt aus:

R6010 - abort() wurde aufgerufen

In früheren Versionen der C-Laufzeitbibliothek wurde diese Meldung angezeigt:

Diese Anwendung hat ein nicht ordnungsgemäßes Beenden der Runtime angefordert. Weitere Informationen erhalten Sie von dem für die Anwendung zuständigen Supportteam.

Wenn das Programm im Debugmodus kompiliert wird, zeigt das Meldungsfeld Optionen zum Abbrechen, Wiederholen oder Ignorieren an. Wenn der Benutzer Abbrechen auswählt, wird das Programm sofort beendet und gibt einen Exitcode von 3 zurück. Wenn der Benutzer Wiederholen auswählt, wird ein Debugger für Just-In-Time-Debuggen aufgerufen, falls verfügbar. Wenn der Benutzer Ignorieren auswählt, fährt abort mit der normalen Verarbeitung fort.

In Verkaufsversionen und Debugbuilds überprüft abort dann, ob ein Abbruchsignalhandler festgelegt ist. Wenn ein nicht standardmäßiger Signalhandler festgelegt ist, ruft abortraise(SIGABRT) auf. Verwenden Sie die signal Funktion, um eine Abbruchsignalhandlerfunktion dem SIGABRT Signal zuzuordnen. Sie können benutzerdefinierte Aktionen wie das Bereinigen von Logressourcen oder Loginformationen ausführen und die App mit Ihrem eigenen Fehlercode in der Handlerfunktion beenden. Wenn kein benutzerdefinierter Signalhandler definiert ist, abort löst das SIGABRT Signal nicht aus.

Standardmäßig ruft in nicht-debug-Builds von Desktop- oder Konsolen-Apps der Windows-Fehlerberichterstattung Service-Mechanismus (vormals Dr. Watson) auf, abort um Fehler an Microsoft zu melden. Dieses Verhalten kann aktiviert oder deaktiviert werden, indem _set_abort_behavior aufgerufen und das _CALL_REPORTFAULT-Flag festlegt oder maskiert wird. Wenn die Kennzeichnung festgelegt ist, zeigt Windows ein Meldungsfeld mit Text wie "Ein Problem verursacht hat, dass das Programm nicht mehr ordnungsgemäß funktioniert" an. Der Benutzer kann einen Debugger mit einer Debugschaltfläche aufrufen oder die Schaltfläche "Programm schließen" auswählen, um die App mit einem vom Betriebssystem definierten Fehlercode zu beenden.

Wenn der Windows-Fehlerberichterstattungshandler nicht aufgerufen wird, rufen Sie _exit aufabort, um den Prozess mit Beendigungscode 3 zu beenden, und gibt die Steuerung an den übergeordneten Prozess oder das Betriebssystem zurück. _exit löscht keine Datenstrompuffer oder verarbeitet atexit/_onexit .

Aus Gründen der Windows-Kompatibilität abort kann beim Aufruf _exitdie Windows-API ExitProcess aufgerufen werden, wodurch dll-Beendigungsroutinen wiederum ausgeführt werden können. Destruktoren werden nicht in der ausführbaren Datei ausgeführt, aber dasselbe gilt möglicherweise nicht für DLLs, die im Prozessbereich der ausführbaren Datei geladen wurden. Dieses Verhalten entspricht nicht streng dem C++-Standard. Verwenden Sie die Windows-API TerminateProcess , um einen Prozess einschließlich aller DLLs sofort zu beenden. Sie können auch einen Abbruchsignalhandler registrieren, der für das standardkonforme Verhalten aufruft TerminateProcess . Das konforme Verhalten kann bei der Windows-Kompatibilität zu bestimmten Kosten führen.

Weitere Informationen zum CRT-Debugging finden Sie unter CRT-Debuggingtechniken.

End Microsoft Specific

Standardmäßig gilt der globale Zustand dieser Funktion für die Anwendung. Informationen zum Ändern finden Sie im Global state in the CRT.

Anforderungen

Routine	Erforderlicher Header
abort	<process.h> oder <stdlib.h>

Beispiel

Das folgende Programm versucht, eine Datei zu öffnen und bricht den Vorgang ab, wenn der Versuch fehlschlägt.

// crt_abort.c
// compile with: /TC
// This program demonstrates the use of
// the abort function by attempting to open a file
// and aborts if the attempt fails.

#include  <stdio.h>
#include  <stdlib.h>

int main( void )
{
    FILE    *stream = NULL;
    errno_t err = 0;

    err = fopen_s(&stream, "NOSUCHF.ILE", "r" );
    if ((err != 0) || (stream == NULL))
    {
        perror( "File could not be opened" );
        abort();
    }
    else
    {
        fclose( stream );
    }
}

File could not be opened: No such file or directory

Siehe auch

Mit abort
abort Funktion
Prozess- und Umgebungskontrolle
_exec, _wexec Funktionen
exit, _Exit, _exit
raise
signal
_spawn, _wspawn Funktionen
_DEBUG
_set_abort_behavior