So kann es gehen...

Um euch an meiner Freude teilhaben zu lassen...
ich habe hier seit Wochen folgenden Code:

int ret = MultiByteToWideChar( CP_ACP, 0, s.data(), s.size(), &ConversionBufferW[0], bufferSize );
		if( ret == ERROR_INSUFFICIENT_BUFFER ) {
                   return "String too long";
                }
// ...

Die Funktion wird bei mir hauptsächlich dazu verwendet, um Exception-Texte in die Unicode-Form zu bringen. Funktionierte auch immer wunderbar.
Nun habe ich heute einen weiteren Teil meines Quellcodes auf Exceptions umgestellt, was erstmal zu Fehlern führte, weil einige catch-Blöcke fehlten. Aber auch nachdem das abgestellt war, dachte ich, dass da etwas entschieden falsch läuft, eventuell mit bösen Folgen auf meinenen Speicherraum, weil die Exception-Texte auf einmal "String too long" lauteten.

Das war wieder so eine Situation, bei der RTFM mal angebracht wäre! Und das nachdem ich vorgestern erst herausgefunden habe, dass boost asio standardmäßig 7-Bit-Transfers auf der seriellen Schnittstelle fährt (zu dem Zeitpunkt hatte ich schon herausgefunden dass die MSB der Datentransfer-Bytes fehlten und alles im Mikrocontroller debugged und überall Breakpoints im Quellcode verteilt, signed zu unsigned Konvertierungen in verschiedensten Varianten ausprobiert etc.).

Martin Richter

so spielt das Programmiererleben...

C++ Forumbot

Dieser Thread wurde von Moderator/in Martin Richter aus dem Forum MFC (Visual C++) in das Forum WinAPI verschoben.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

knivil

Welchen Grund gibt esk, in Exceptionbeschreibungen Unicode zu verwenden?

Martin Richter

knivil schrieb:

Welchen Grund gibt esk, in Exceptionbeschreibungen Unicode zu verwenden?

Weil zum Beispiel in der Beschreibung Daten fr die Ursache vorligen, die wiederum in Unicode gespeichert sind...

Ich habe hier ein "komplizierte" Initialisierungsroutine mit phasenweiser Initialisierung von benutzerdefinierten Konstrukten. Diese ist _mit Abstand_ am übersichtlichsten zu implementieren unter Verwendung von Exceptions, auch wenn man sagen könnte, dass hier nicht unbedingt fatale Fehler in dem Sinne, dass sie nicht erkannt wurden, stattfinden (ich gehe inzwischen auch manchmal Kompromisse ein). Und hinterher sollen die erkannten Probleme dem Benutzer einigermaßen lesbar dargestellt werden und das in einem Programm, dessen Logging-Funktionalität eben auf Unicode ausgelegt ist.

knivil

Martin Richter schrieb:

Weil zum Beispiel in der Beschreibung Daten fr die Ursache vorligen, die wiederum in Unicode gespeichert sind...

Naja, das ist mir klar. Aber warum tut man das. Ich meine wenn mehrere Sprachen mit anderen Zeichensaetzen unterstuetzt werden sollen. Aber bei Exceptions ... ich meine ich gebe der Exception doch nicht beim Werfen mit, was die GUI als Fehlermeldung anzeigen soll. Nun gut Logging in Unicode vielleicht.

Martin Richter

Und warum nicht?

Warum sollte ich nciht eine Excpetion bauen bzgl. eines DB/XML/Makro Feldes, das in der UI als Unicode angezeigt werden muss...

knivil

Da eine Exception eher etwas technisches ist und ein User nichts damit anfangen kann? Auch geht es hier um ein eingebettetes System mit dem ueber die serielle Schnittstelle kommuniziert wird. Dabei handelt es sich wahrscheinlich um Englisch/Deutsch als Fehlermeldung und nicht um einen chinesischen Datenbankeintrag.