Ich habe den folgenden Code auf VS2008 gefunden
%Vor%Jetzt portiere ich den Code zu mingw gcc und bekomme den Fehler
%Vor%Bei der Untersuchung des Problems ist mir aufgefallen, dass Visual Studio eine Dateiausnahme hat, die eine Ausnahmeklasse hat und char * aufnimmt. Einige der Definitionen sehen so aus:
%Vor%Meine Frage ist, wie ich dieses Build-Problem auf mingw gcc umgehen soll? Soll ich eine neue Klasse erstellen, die von std :: runtime_error erbt und diese stattdessen ausliest?
Meinung spielt hier eine Rolle. Das Problem ist, dass std::exception keinen Konstruktor hat, der ein String-Argument akzeptiert; Dies ist eine MSVC-Erweiterung. Ich sehe zwei Möglichkeiten:
std::exception
Der erste Fall ist einfach; benutze einfach
%Vor%Der Nachteil ist, dass Sie keine beschreibende Fehlermeldung erhalten.
Wenn die Fehlermeldung wichtig ist, ist die direkte Verwendung von std::exception keine Option. In diesem Fall könnten Sie entweder std::logic_error oder std::runtime_error verwenden, die std::exception erben und Konstruktoren, die ein String-Argument verwenden, also
könnte das Problem bereits lösen. catch -Klauseln, die std::exception abgefangen haben, fangen auch std::runtime_error ab. Es gibt jedoch ein mögliches Problem: catch -Klauseln, die std::runtime_error fangen, hätten std::exception nicht abgefangen, sondern fangen dieses ein.
Dies scheint ein bisschen wie ein Eckfall zu sein, und es ist durchaus möglich, dass es kein Problem für Sie ist. Wenn jedoch die Möglichkeit besteht, dass in der Aufrufliste eine catch -Klausel vorhanden ist, die std::runtime_error abfängt, aber die von diesem Code ausgelöste Ausnahme nicht abfangen soll, können Sie Ihre eigene Exception-Klasse von std::exception ableiten ein String-Argument. Da die Klasse neu ist, wird sie nicht von vorhandenen catch -Klauseln abgefangen. Zum Beispiel:
Und dann
%Vor% Dies ist wohl nicht sehr hübsch, und es ist unwahrscheinlich, dass es notwendig ist, also ist die wahrscheinlichere Lösung, std::runtime_error oder std::logic_error (oder eine von einem von ihnen abgeleitete Klasse) zu verwenden.
Ob std::logic_error oder std::runtime_error angemessener ist, ist nicht sehr eindeutig. In diesem Fall würde ich wahrscheinlich mit std::runtime_error gehen, weil der Fehler nicht einmal theoretisch vorhersehbar erscheint, aber da std::domain_error und std::future_error von std::logic_error abgeleitet sind, wäre es in dieser Hierarchie nicht völlig fehl am Platz. Das ist, denke ich, eine Frage der Meinung.
Tags und Links c++ gcc visual-studio c++11