brauchen ein robustes Fehlersystem für eine Win32-GUI-Anwendung

Question

Ich habe einige Codes, der wie folgt aussieht:

void MyClass::OnButtonClick() 
{ 
    int retVal = SomeDialog.DoModal(); 
    if(retVal == MYCLASS_ERROR) 
    { 
     MessageBox("Error"...blah ...blah); 
    } 
    else if(retVal == IDOK) // IDOK is returned on clicking the 'OK' button 
    { 
     MessageBox("All is well"...blah ...blah); 
    } 
} 

• SomeDialog nur zeigt einen Fortschrittsbalken. Bei jedem Fehler wird der Fortschrittsbalken automatisch durch den Aufruf von EndDialog(MYCLASS_ERROR) geschlossen. Nur bei erfolgreichem Abschluss kann der Benutzer dort auf "OK" klicken.
• MYCLASS_ERROR ist ein Wert in einem enum, der alle Arten von Rückgabetypen und Status enthält.

Ich fand, dass beim Klicken auf OK in SomeDialog die Fehlermeldung immer noch angezeigt wird! Ich grub ein wenig tiefer und fand, dass MYCLASS_ERROR = IDOK = 1.

Also meine Frage ist, wie soll ich all diese Rückkehr Zustände so definieren, dass sie nicht mit anderen Implementierung des Status kollidiert? Bedeutung, meine Funktionen sollten Werte zurückgeben, die nicht von anderen anderen Funktion zurückgegeben werden (oder so wenige andere Funktionen wie möglich).

Ich dachte an mein Design so zu ändern, dass alle Funktionen nur TRUE oder FALSE zurückgaben. Dies wäre jedoch nicht in allen Fällen möglich. Ich habe auch einiges nach Antworten gesucht und bisher noch keine gefunden.

Danke fürs schauen!

Answer 1

Es gibt Möglichkeiten, dies zu umgehen, aber sie sind irgendwie hässlich. Das sauberste Design ist normalerweise dasjenige, das das Zusammenstoßen mit Standard Win32-Idiomen vermeidet, und in der Welt von Win32 geben modale Dialoge einen der ID Werte zurück, um die Schaltfläche anzugeben, auf die der Benutzer geklickt hat, wenn er sie abbrach (genau wie Nachrichtenfelder)). Streng genommen ist es der nResult Parameter, der an die EndDialog Funktion übergeben wurde, die zum Schließen des modalen Dialogfelds verwendet wird.

Ich empfehle nicht zu versuchen, diesen Rückgabewert mit zusätzlicher Bedeutung zu überladen. Der Versuch, dies zu tun, führt Sie nur in Schwierigkeiten (zum Beispiel haben Sie wahrscheinlich auch noch nicht bemerkt, dass ein Rückgabewert von -1 bedeutet, dass die Erstellung des Dialogfelds fehlschlug).

Definieren Sie stattdessen eine zusätzliche Elementvariable in Ihrer Dialogklasse und verwenden Sie diese, um Ihre zusätzlichen Informationen zu melden. Bei Erfolg geben Sie IDOK aus dem Dialogfeld zurück. Bei einem Fehler (beliebig Art des Fehlers), geben Sie etwas wie IDCANCEL zurück. Ihr Code innerhalb von OnButtonClick würde dann prüfen, ob der Rückgabewert IDOK oder IDCANCEL ist. Wenn es IDCANCEL ist, müssen Sie auch den Wert der Mitgliedsvariablen abfragen, die Sie dem Dialog für zusätzliche Information hinzugefügt haben.

Hoffentlich machte das Sinn.Wenn nicht, vielleicht wird dieser Code Beispiel (unter der Annahme, dass m_errStatus ist die Membervariable Sie Ihre Unterklasse von CDialog hinzugefügt):

void MyClass::OnButtonClick() 
{ 
    if (SomeDialog.DoModal() == IDOK) 
    { 
     // Success! 
     // The OK button was clicked, so IDOK was returned. 
     MessageBox("All is well"...blah ...blah); 
    } 
    else 
    { 
     // Failure! 
     // Some error occurred, so IDCANCEL (or any other value) was returned. 
     // Determine what to do now, based on additional information that the 
     // dialog set upon failure. 
     switch (SomeDialog.m_errStatus) 
     { 
      case MYCLASS_ERROR_1: 
       MessageBox("Error 1 occurred."); 
       break; 
      case MYCLASS_ERROR_2: 
       MessageBox("Error 2 occurred."); 
       break; 
      // etc. 
     } 
    } 
} 

Answer 2

Sie können enum anstelle von macro-defined-Returncode mit Namespace verwenden, um Namenskonflikte zu vermeiden. Schauen Sie sich die Boost Error Handling Policy:

namespace boost { namespace math { namespace policies { 

enum error_policy_type 
{ 
    throw_on_error = 0, // throw an exception. 
    errno_on_error = 1, // set ::errno & return 0, NaN, infinity or best guess. 
    ignore_error = 2, // return 0, NaN, infinity or best guess. 
    user_error = 3 // call a user-defined error handler. 
}; 

}}} // namespaces 

Answer 3

Sie einfach Ihre benutzerdefinierten Fehlercodes definieren könnten nicht „kollidieren“ mit den Windows-Rückgabewerten . Natürlich wissen Sie nicht, wann Microsoft neue Rückgabewerte hinzufügen wird, also wird dies immer ein bisschen flakey sein.

Man könnte so etwas wie dies versucht:

enum MYERR 
{ 
    MYERR_FIRST_ERROR = 0x0F000000, /* large and unlikely to be used */ 
    MYERR_SECOND_ERROR, 
    MYERR_THIRD_ERROR, 
    /* and so on */ 
}; 

Aber, wie Cody Grau oben bemerkt, ich glaube, du bist besser dran mit einem Standard-Fehlercode aus DoModal Rückkehr, wie IDABORT stattdessen die Rückgabecodes von Überlastung so wie das. Dann haben Sie einfach einen sekundären Fehlercode, den Benutzer explizit abrufen müssen, was Ihr eigener "interner" Fehlercode ist.