C++11-Buch gesucht
-
SeppJ schrieb:
Ich bastel damit andauernd Strings für Exceptionmeldungen zusammen. Bin ich da so ungewöhnlich? So bekommt man viel leichter Information über die Ausnahmeursache in die Standardexceptions.
Du bist ungewöhnlich. Oder verhältst dich zumindest entgegen allgemein anerkannter C++-Richtlinen.
http://www.boost.org/community/error_handling.html schrieb:
Format the what() message on demand, if you feel you really must format the message. [...]
Don't worry too much about the what() message. It's nice to have a message that a programmer stands a chance of figuring out, but you're very unlikely to be able to compose a relevant and user-comprehensible error message at the point an exception is thrown. Certainly, internationalization is beyond the scope of the exception class author. Peter Dimov makes an excellent argument that the proper use of a what() string is to serve as a key into a table of error message formatters. Now if only we could get standardized what() strings for exceptions thrown by the standard library...
-
stdexcept schrieb:
http://www.boost.org/community/error_handling.html schrieb:
Format the what() message on demand, if you feel you really must format the message. [...]
Don't worry too much about the what() message. It's nice to have a message that a programmer stands a chance of figuring out, but you're very unlikely to be able to compose a relevant and user-comprehensible error message at the point an exception is thrown. Certainly, internationalization is beyond the scope of the exception class author. Peter Dimov makes an excellent argument that the proper use of a what() string is to serve as a key into a table of error message formatters. Now if only we could get standardized what() strings for exceptions thrown by the standard library...
Und wenn man schon mal dabei ist, standardisierte type_info::name.
-
Nathan schrieb:
Und wenn man schon mal dabei ist, standardisierte type_info::name.
Was hat das damit zu tun? Abgesehen davon wird type_info::name maximal für Debuggingzwecke gebraucht.
Mein wichtigster Abschnitt ist hier:
the proper use of a what() string is to serve as a key into a table of error message formatters
-
stdexcept schrieb:
Nathan schrieb:
Und wenn man schon mal dabei ist, standardisierte type_info::name.
Was hat das damit zu tun? Abgesehen davon wird type_info::name maximal für Debuggingzwecke gebraucht.
Mein wichtigster Abschnitt ist hier:
the proper use of a what() string is to serve as a key into a table of error message formatters
Ja, klar.
Aber wenn man schon die Exceptions-Messages standadisiert, kann man auch gleich std::type_info::name() standardisieren. Die Funktion hätte eigentlich Potenzial als Type Identifier in Object Factories, aber so...
-
stdexcept schrieb:
SeppJ schrieb:
Ich bastel damit andauernd Strings für Exceptionmeldungen zusammen. Bin ich da so ungewöhnlich? So bekommt man viel leichter Information über die Ausnahmeursache in die Standardexceptions.
Du bist ungewöhnlich. Oder verhältst dich zumindest entgegen allgemein anerkannter C++-Richtlinen.
Ich schreibe die Fehlermeldungen nicht für Benutzer. Ich schreibe sie für mich. Für mich ist die Info aus what() sehr aufschlussreich, wenn man sie bloß reinpackt. Was mit to_string trivial einfach ist.
-
SeppJ schrieb:
Ich schreibe die Fehlermeldungen nicht für Benutzer. Ich schreibe sie für mich.
Tut mir leid, dann habe ich falsch zitiert.
As a developer, if I have violated a precondition of a library I'm using, I don't want stack unwinding. What I want is a core dump or the equivalent - a way to inspect the state of the program at the exact point where the problem was detected. That usually means assert() or something like it.
Es gibt nichts besseres um Programmierfehler zu finden als assert(). Ich sehe sofort das Problem und kann mir vom Debugger alles anzeigen lassen, was ich will.
Ich weiss noch, wie viel Zeit ich in meinem Java-Projekt reingesteckt habe, schöne Exception-Messages zu generieren (da ging das einfach mit "+", ohne das verbose to_string), nur um am Ende einen Breakpoint auf jedes throw zu setzen...
-
stdexcept schrieb:
Ich weiss noch, wie viel Zeit ich in meinem Java-Projekt reingesteckt habe, schöne Exception-Messages zu generieren (da ging das einfach mit "+", ohne das verbose to_string), nur um am Ende einen Breakpoint auf jedes throw zu setzen...
Schließe aus deiner suboptimalen Nutzung von Features nicht auf andere.
-
SeppJ schrieb:
stdexcept schrieb:
Ich weiss noch, wie viel Zeit ich in meinem Java-Projekt reingesteckt habe, schöne Exception-Messages zu generieren (da ging das einfach mit "+", ohne das verbose to_string), nur um am Ende einen Breakpoint auf jedes throw zu setzen...
Schließe aus deiner suboptimalen Nutzung von Features nicht auf andere.
Wäre es zu viel verlangt, ein sinvolles Beispiel von Exceptions mit ausführlicher Fehlermeldung zu bringen?
-
stdexcept schrieb:
Wäre es zu viel verlangt, ein sinvolles Beispiel von Exceptions mit ausführlicher Fehlermeldung zu bringen?
throw std::thread_exception("Troll found. Name: " + username);
-
SeppJ schrieb:
stdexcept schrieb:
Wäre es zu viel verlangt, ein sinvolles Beispiel von Exceptions mit ausführlicher Fehlermeldung zu bringen?
throw std::thread_exception("Troll found. Name: " + username);Schön getrollt. Und was passiert dann mit der Message?
-
stdexcept schrieb:
Und was passiert dann mit der Message?
Sie wird gelesen. Weil sie nützlich ist.
-
SeppJ schrieb:
stdexcept schrieb:
Und was passiert dann mit der Message?
Sie wird gelesen. Weil sie nützlich ist.
Von wem?
SeppJ schrieb:
Ich schreibe die Fehlermeldungen nicht für Benutzer. Ich schreibe sie für mich.
Ah, der Benutzer schickt sie dir per Mail zu, wenn ein Fehler auftritt (und er muss auftreten, weil sonst gäbe es keinen Grund, nicht Assertions zu verwenden).
Aber der Benutzer bekommt sie trotzdem vor Gesicht. Vernünftige Softwarebetriebe würde solche Messages von UI-Experten anschauen und übersetzen lassen.
-
asserts und Exception sind verschiedene Dinge!
assert() wird eingesetzt um bspw. bei operator[] zu prüfen ob i < size ist.
Exceptions werden eingesetzt, wenn der OpenGL Kontext nicht erstellt wurde.
Und wenn der Benutzer dann eine Messagebox vors Gesicht bekommt, wie z.B.:Es ist eine Ausnahme aufgetreten. Fehler: "my::win::opengl_context::create: unable to create context" Bitte kontaktieren Sie das Supportteam., weiß der User was zu tun ist und die Supporter wo der Fehler liegt.
-
Schließ nicht von deinen DAU-Nutzern auf andere.
Schließ auch nicht von deiner "Erfahrung" als Anwendungsentwickler, dass alle Leute Endanwendersoftware schreiben.
Dein Horizont ist einfach schwer beschränkt, wenn du keine Nützlichkeit in nützlichen Meldungen siehst.
-
Ihr beide geht extrem Off-Topic. Splitte doch wenigstens den Thread, SeppJ.
-
Nathan schrieb:
asserts und Exception sind verschiedene Dinge!
assert() wird eingesetzt um bspw. bei operator[] zu prüfen ob i < size ist.
Exceptions werden eingesetzt, wenn der OpenGL Kontext nicht erstellt wurde.Falsch. Asserts werden eingesetzt, wenn der Fehler so gravierend ist, dass das Programm nicht sinnvoll fortgesetzt werden kann. Exceptions sind dazu gedacht, wenn du Stack Unwinding zum nächsten sinnvollen State machen willst.
Du kannst z.B. ein assert() schreiben, das eine Messagebox aufmacht und anschliessend das Programm beendet.
"Es ist ein Fehler aufgetreten: "kontextersteller.cpp:42:13: create_context(): context!=NULL" Bitte kontaktieren Sie das Supportteam.
Exceptions haben da einfach keinen Mehrwert.
Schließ nicht von deinen DAU-Nutzern auf andere.
Wie wäre es, wenn du aufhörst, andere zu beleidigen und sachliche Argumente lieferst?
Schließ auch nicht von deiner "Erfahrung" als Anwendungsentwickler, dass alle Leute Endanwendersoftware schreiben.
Ich gehe davon aus, dass deine Software irgendwelche Kunden hat.
Dein Horizont ist einfach schwer beschränkt, wenn du keine Nützlichkeit in nützlichen Meldungen siehst.
Ich sehe sehr wohl eine Nützlichkeit in nützlichen Meldungen. Der Punkt ist nur, dass deine Meldungen nur für den Entwickler nützlich sind. Das kann auch assert().
Nützliche Meldungen mit Exceptions erreicht man durch
the proper use of a what() string is to serve as a key into a table of error message formatters
-
stdexcept schrieb:
Nathan schrieb:
asserts und Exception sind verschiedene Dinge!
assert() wird eingesetzt um bspw. bei operator[] zu prüfen ob i < size ist.
Exceptions werden eingesetzt, wenn der OpenGL Kontext nicht erstellt wurde.Falsch. Asserts werden eingesetzt, wenn der Fehler so gravierend ist, dass das Programm nicht sinnvoll fortgesetzt werden kann. Exceptions sind dazu gedacht, wenn du Stack Unwinding zum nächsten sinnvollen State machen willst.
Du kannst z.B. ein assert() schreiben, das eine Messagebox aufmacht und anschliessend das Programm beendet.
"Es ist ein Fehler aufgetreten: "kontextersteller.cpp:42:13: create_context(): context!=NULL" Bitte kontaktieren Sie das Supportteam.
Dumm nur, dass asserts im Release-Build gar nicht mehr auftauchen sollten!
Und ich denke es gibt nichts gravierenderes als einen SegFault.
Läuft ein Programm im Debug mit assert, läuft es auch im Release ohne assert.
Dinge wie "File not found" oder "not enough memory" oder "unable to create context", die abhängig vom User sind, werden mit exceptions gelöst.
-
stdexcept schrieb:
Dein Horizont ist einfach schwer beschränkt, wenn du keine Nützlichkeit in nützlichen Meldungen siehst.
Ich sehe sehr wohl eine Nützlichkeit in nützlichen Meldungen. Der Punkt ist nur, dass deine Meldungen nur für den Entwickler nützlich sind. Das kann auch assert().
Dann schreib nochmal an die Macher der Standardbibliothek, dass sie doch bitte ein assert in malloc/new einbauen sollen. Ach, macht keinen Sinn, obwohl nur Entwickler jemals eine bad_alloc zu Gesicht bekommen! Wer hätte das erwartet?
Wenn doch jetzt bloß bei einer "file not found"-Exception noch dabei stünde, welche Datei nicht gefunden wurde. Ach, tut es! Vollkommen nutzlos! Welcher Entwickler baut so etwas ein? Haben die wohl deine schlauen Sprüche nicht gelesen.
Wenigstens steht bei einem doppelten free oder heap corruption nicht dabei, an welcher Adresse der Fehler auftrat. Ach, tut es! Anscheinend hast du auf der Welt noch viel Überzeugungsarbeit zu leisten.
-
SeppJ schrieb:
Dann schreib nochmal an die Macher der Standardbibliothek, dass sie doch bitte ein assert in malloc/new einbauen sollen. Ach, macht keinen Sinn, obwohl nur Entwickler jemals eine bad_alloc zu Gesicht bekommen! Wer hätte das erwartet?
In bad_alloc steht kein schlaues what().
SeppJ schrieb:
Wenn doch jetzt bloß bei einer "file not found"-Exception noch dabei stünde, welche Datei nicht gefunden wurde. Ach, tut es! Vollkommen nutzlos! Welcher Entwickler baut so etwas ein? Haben die wohl deine schlauen Sprüche nicht gelesen.
Zumindest bei Boost wird die Meldung des Betriebssystems zurückgegeben und das wird übersetzt (auf Deutsch z.B.).
Dein Text wird das nicht, deshalb ist er nutzlos.SeppJ schrieb:
Wenigstens steht bei einem doppelten free oder heap corruption nicht dabei, an welcher Adresse der Fehler auftrat. Ach, tut es! Anscheinend hast du auf der Welt noch viel Überzeugungsarbeit zu leisten.
double-free und heap corruption ist normalerweise ein assert.
Nathan schrieb:
Dumm nur, dass asserts im Release-Build gar nicht mehr auftauchen sollten!
Dumm nur, dass mich niemand daran hindert, verschiedene Arten von asserts zu schreiben. Das macht deine Argumentation hinfällig.
-
stdexcept schrieb:
Dumm nur, dass mich niemand daran hindert, verschiedene Arten von asserts zu schreiben. Das macht deine Argumentation hinfällig.
an welcher stelle ds programms weißt du denn a-priori ob du ein debug doer release assert brauchst? Und wenn du das release assert ohne exception baust, werden dir die user die bude vollkotzen, weil das exit() verhindert das die Datenbank noch ordentlich geschlossen wird und sie jetzt eine inkonsistente Datenhaltung haben.
noch so tolle Ideen um einfach mal recht zu haben?
