Wann liefern die WinAPI-Funktionen einen Fehler zurück?

[Waper]

Die ganzen WinAPI-Funktionen zur GUI und zum Zeichnen können ja theoretisch einen Fehler zurückliefern. Zum Beispiel CreateWindow oder BitBlt. Aber wann würde das in der Praxis eigentlich jemals passieren?

Kann es sein, dass eine Zeichenaktion mit BitBlt eben noch funktionierte und jetzt nicht mehr, so dass ich im Programm tatsächlich besser eine Fehlerprüfung einbaue? Oder schlägt die Funktion nur fehl, wenn zum Beispiel falsche Parameter angegeben wurden (negativer Wert bei einem der Integers) oder ich generell fehlerhaft programmiert habe (HDCs werden nicht freigegeben)?

Ich würde gerne mehr dazu erfahren, weil ich generell wissen möchte, wann es sinnvoll ist, den Rückgabewert abzuprüfen, weil auf dem System des Benutzers etwas fehlschlagen kann, und wann es ausreicht, die Funktion einfach so laufen zu lassen, weil ein auftretender Fehler lediglich mit einem schlampigen Code zu tun hat.

[Martin Richter]

Alle Aufrufe können fehlschalgen, speziell bei Low-Memory-Conditions.

Das erzeugen eines fensters prüfe ich grundsätzlich. Denn alles andere könnte zu Crashes führen (hWnd eben NULL).

Wenn ein BitBlt fehlgeht ist mir das egal. Wenn etwas falsch anmgezeigt wird ist das die Vorstufe von mindestens einem späteren Problem, spätestens wenn das nächste Fenster benötigt wird oder anders Speicher allokiert wird, oder ein wetres GDI-Handle.

Viele MFC Operati0onen werfen hier Exceptions.

Wenn Dein BitBlt fehlgeht, dann vermutlich weil Du ein Handle-Leak hast...

[Waper]

Kann so ein Handle-Leak nur auftreten, wenn ich irgendwas falsch programmiert habe oder auch sonst?

Worum es mir nämlich geht: Angenommen, ich programmiere ein kleines Spiel mit der GDI. (Ja, ich weiß, es gibt bessere Libraries. Nur mal angenommen.) Wäre es dann ratsam, die ganzen WinAPI-Funktionen folgendermaßen zu wrappen?

namespace Win
{
    void BitBlt(HDC dest, int x, int y, int w, int h, HDC src, int xSrc, int ySrc, DWORD rop)
    {
        if (!::BitBlt(dest, x, y, w, h, src, xSrc, ySrc, rop)
            throw WinException("BitBlt");
    }
}

Und dann in der WinMain die WinException (das wäre dann eine von mir programmierte Exception) abzufangen? Oder wäre das Overkill?

PS: In dem Fall würde ich übrigens sämtliche Handle-Typen in RAII-Klassen wrappen, so dass die sich beim Werfen einer Exception sauber wieder löschen, indem dann im Destruktor die entsprechende Funktion (DeleteObject oder ReleaseDC etc.) aufgerufen wird.

[Waper]

Zusatz:

Martin Richter schrieb:

Wenn Dein BitBlt fehlgeht, dann vermutlich weil Du ein Handle-Leak hast...

Es ist übrigens nicht so, dass mein BitBlt fehlschlägt. Ich fragte nur, weil es eben noch nie fehlgeschlagen ist und ich jetzt nicht sicher bin, in wie weit die Fehlerbehandlung in der realen Praxis wirklich sinnvoll ist.

[Martin Richter]

Nö. Halte ich nicht für sinnvoll.

Ich prüfe nur da Fehler wo Ressourcen alloziert werden.
Oder Operationen durchgeührt werden deren Erfolg für mein Programm notwendig ist.

Ob was angezeigt wurde oder nichtist mir wurscht.
Aber es ist mir nicht wurscht, wenn eine Zeile nicht in ein List-Control gepackt werden konnte, oder ein FOnt nicht erzeugt wurde, oder oder oder.