Exceptions avec Unicode what()

Question

Ou, "comment les Russes lancent-ils des exceptions ?".

La définition de std::exception est :

namespace std {
  class exception {
  public:
    exception() throw();
    exception(const exception&) throw();
    exception& operator=(const exception&) throw();
    virtual ~exception() throw();
    virtual const char* what() const throw();
  };
}

A école populaire de pensée pour concevoir des hiérarchies d'exceptions est de dériver de std::exception :

En général, il est préférable de lancer des objets, pas des meubles. Si possible, vous devriez lancer des instances de classes qui dérivent (en dernier ressort) de la classe std::exception . En faisant en sorte que votre classe d'exception hérite (en dernier ressort) de la classe de base standard de base des exceptions, vous vous vie plus facile pour vos utilisateurs (ils ont l'option d'attraper la plupart des choses via std::exception), et vous leur fournissez probablement leur fournir plus d'informations (comme le fait que votre exception particulière peut être un raffinement de std::runtime_error ou autre).

Mais face à Unicode, il semble impossible de concevoir une hiérarchie d'exceptions permettant d'atteindre les deux objectifs suivants :

• Dérive ultimement de std::exception pour faciliter l'utilisation du site catch.
• Assure la compatibilité Unicode pour que les diagnostics ne soient pas des tranches ou du charabia.

Il est assez simple de créer une classe d'exception qui peut être construite avec des chaînes Unicode. Mais la norme stipule que what() doit retourner un const char*, donc à un moment donné, les chaînes d'entrée doivent être converties en ASCII. Que cela soit fait au moment de la construction ou lorsque what() est appelé (si la chaîne source utilise des caractères non représentables par l'ASCII 7 bits), il peut être impossible de formater le message sans perte de fidélité.

Comment concevoir une hiérarchie d'exceptions qui combine l'intégration transparente d'une classe dérivée de std::exception avec des diagnostics Unicode sans perte ?

Answer 1

Char* ne signifie pas ASCII. Vous pouvez utiliser un encodage Unicode 8 bits comme UTF-8. char peut aussi être 16 bits ou plus, vous pouvez alors utiliser UTF-16.

Answer 2

Renvoyer UTF-8 est un choix évident. Si l'application qui utilise vos exceptions utilise un codage multi-octets différent, elle pourrait avoir du mal à afficher la chaîne de caractères. (Elle ne peut pas savoir que c'est UTF-8, n'est-ce pas ?) D'un autre côté, pour les encodages 8 bits ISO-8859-* (Europe de l'Ouest, cyrillique, etc.), l'affichage d'une chaîne UTF-8 ne fera qu'afficher du charabia et cela peut vous convenir (ou à votre utilisateur) si vous ne pouvez pas faire la distinction entre un char* dans le jeu de caractères local et UTF-8.

Personnellement, je pense que seuls les messages d'erreur de bas niveau devraient aller dans les chaînes what() et personnellement, je pense que ceux-ci devraient être en anglais de toute façon. (Peut-être combiné avec un numéro d'erreur ou autre).

Le pire problème que je vois avec what() est qu'il n'est pas rare d'inclure certains détails contextuels dans le message what(), par exemple une nom de fichier . Les noms de fichiers sont non ASCII assez souvent, vous n'avez donc pas d'autre choix que d'utiliser UTF-8 en tant que what() l'encodage.

Notez également que votre classe d'exception (qui est dérivée de std::exception) peut évidemment fournir toutes les méthodes d'accès que vous souhaitez et qu'il pourrait donc être judicieux d'ajouter une fonction explicite what_utf8() o what_utf16() o what_iso8859_5() .

Edit : Concernant le commentaire de John sur la façon de retourner UTF-8 :

Si vous avez un const char* what() cette fonction renvoie essentiellement un tas d'octets. Sur une plateforme Windows d'Europe de l'Ouest, ces octets sont généralement codés comme suit Win1252 mais sur un Windows russe, cela pourrait aussi bien être Win1251 .

Ce que les octets retournés signifient dépend de leur encodage et leur encodage dépend de leur "origine" (et de la personne qui les interprète). L'encodage d'une chaîne littérale est défini au moment de la compilation, mais au moment de l'exécution, c'est à l'application de décider comment l'interpréter.

Donc, pour que votre exception renvoie des chaînes UTF-8 avec what() (ou what_utf8() ) vous devez vous assurer que :

• Le message d'entrée de votre exception a un codage bien défini
• Vous disposez d'un encodage bien défini pour le membre de la chaîne de caractères que vous utilisez pour contenir le message.
• Vous convertissez le codage de manière appropriée lorsque what() s'appelle

Exemple :

struct MyExc : virtual public std::exception {
  MyExc(const char* msg)
  : exception(msg)
  { }
  std::string what_utf8() {
    return convert_iso8859_1_to_utf8( what() );
  }
};

// In a ISO-8859-1 encoded source file
const char* my_err_msg = "ISO-8859-1 ... äöüß ...";
...
throw MyExc(my_err_msg);
...
catch(MyExc const& e) {
  std::string iso8859_1_msg = e.what();
  std::string utf_msg = e.what_utf8();
...

La conversion pourrait également être placée dans la fonction membre (surchargée) what() de MyExc(). ou vous pourriez définir l'exception pour qu'elle prenne une chaîne de caractères déjà codée en UTF-8 ou vous pourriez convertir (à partir d'un encodage d'entrée attendu, peut-être wchar_t/UTF-16) dans le ctor.

Answer 3

La première question est de savoir ce que vous avez l'intention de faire avec la chaîne what().

Prévoyez-vous d'enregistrer ces informations quelque part ?

Si c'est le cas, vous ne devriez pas utiliser le contenu de la chaîne what(), mais plutôt utiliser cette chaîne comme référence pour rechercher la bonne réponse. local un message de journalisation spécifique. Selon moi, le contenu de la fonction what() n'est pas destiné à la journalisation (ou à toute forme d'affichage), mais à la recherche de la chaîne de journalisation (qui peut être n'importe quelle chaîne Unicode).

Maintenant, il peut être utile que la chaîne what() contienne un message lisible par l'homme pour les développeurs afin d'aider à un débogage rapide (mais pour cela, un texte poli très lisible n'est pas nécessaire). Par conséquent, il n'y a aucune raison de prendre en charge autre chose que l'ASCII. Respectez le principe KISS.

Answer 4

Un const char* n'a pas besoin de pointer vers une chaîne ASCII ; il peut être dans un encodage multi-octet tel que UTF-8. Une option consiste à utiliser wcstombs() et ses amis pour convertir les wstrings en strings, mais vous pouvez avoir à convertir le résultat de what() en wstring avant l'impression. Cela implique également plus de copie et d'allocation de mémoire que ce que vous pouvez supporter dans un gestionnaire d'exception.

En général, je définis simplement ma propre classe d'exception de base, qui utilise wstring au lieu de string dans le constructeur et renvoie un const wstring& à partir de what() . Ce n'est pas si grave. L'absence d'un standard est un gros oubli.

Une autre opinion valable est que les chaînes d'exception ne doivent jamais être présentées à l'utilisateur, de sorte que leur localisation n'est pas nécessaire et que vous n'avez pas à vous soucier de ce qui précède.

Answer 5

Le minimum absolu que tout développeur de logiciels doit absolument, positivement connaître sur Unicode et les jeux de caractères (pas d'excuses !) par Joel Spolsky

Edit : Made CW, les commentateurs peuvent ajouter la raison pour laquelle ce lien est pertinent s'ils le souhaitent.