views:

182

answers:

6

Say I have a huge amount of code and have different kinds of error messages. For these, I want to have a separate place where I store error codes and error messages. For example, for an error that occured because the program could not open a file I store:

F001    "Can not open a file." "The same error message in another language" "The same error message in a third language"

What is the best way to store different kinds of error messages and codes in a file for C++ programmers in order to use them quickly and easily in a programme?

FYI I am working with the Qt lib.

+2  A: 

You can put them in your resource bundle, where all other strings are. Then use their resource code and you will have the benefit, that all error messages are translated in the different languages

m_pGladiator
In MFC I have used strings as resources, but does Qt has that kind of means?
Narek
Yes. Qt does handle string resources.
Cogwheel - Matthew Orlando
LoadString(LoadStringA/LoadStringW) are available regardless of GUI toolset http://msdn.microsoft.com/en-us/library/ms647486%28VS.85%29.aspx
Greg Domjan
+1, this in combination with Qt Linguist that gives you internationalization.
Ton van den Heuvel
A: 

Which O/S? On Windows, one standard but relatively complicated way is to use Message Files.

ChrisW
A: 

In actually prefer to generate error messages in the body of the code rather than keep them in a separate file - for example (picked at random from my own code):

if ( ev[0] != SUB_CMD ) {
    CSVTHROW( "Invalid edit sub-command '" << ev[0] << "' in '" << ev << "' " );
}

This is for three reasons:

  • It allows for more inteligible error messages, with the invalid values interspersed with the message text

  • Associating the error test directly with the message makes it clear what is going on

  • I have seen too many projects which used the WRONG error code for an error, which is hard to test for and causes immense confusion. For example if F001 is your file open error, then I've seen lots of code like this:

-

if ( login_invalid() ) {
   ERROR( "F001" );
}

Of course, doing this makes internationalisation hard, but that's not a concern for the kind of projects I do.

anon
Yes, but to have a one place where you define and then use the same thing, assures that you will not generate different error messages for the same situation. Also it is visible (if it's in one file) what kind of situations you have processed (worked up) and what is left to process yet. And also for my project internationalization is a big concern, because, as I have noted, "I have a huge code".
Narek
@Narek If it's the same situation, it should be in the same function. In other words, have a common function for opening files and reporting errors if they fail to open.
anon
It is not always like that, unfortunately. I meant you could have different sitations but the same problem - the same error.
Narek
Have you found a spell checker that will check only "" strings in a source file? That's why I use an external strings header
Martin Beckett
@Martin No, but I don't consider that a major problem. Putting all the error messages in a C++ header OTOH has the problem that whenever you add or change a message you will have to rebuild the entire project.
anon
@Martin: Yes: Kate can do spell checking on only "" strings and comments. (http://kate-editor.org/)
Job
String concatenation is bad for internationalization
Greg Domjan
@Greg Did you bother to read what I wrote?
anon
"but that's not a concern for the kind of projects I do." But it *was* a concern in the question. ;) Since he's using Qt, it seems like string resources + Qt's localization would be the best way to go...
Cogwheel - Matthew Orlando
@Cogwheel The stuff in the question about "another language" was added after I answered, as was the fact that he is using Qt.
anon
*shrug* to quote "in actually prefer to generate error messages in the body of the code rather than keep them in a separate file". <meta> I'm sorry I came to your message after the original post changed, but to me it didn't answer the question asked at the time. I thought that was how the system worked...
Greg Domjan
+1  A: 

I would use XML like this:

<languageList>
    <language short="de" long="Deutsch" default="true" />
    <language short="en" long="English" />
</languageList>
<string alias="couldNotOpenFileError"
    de="Konnte Datei nicht öffnen"
    en="Could not open file"
    />
<string alias="couldNotWriteFileError"
    de="Konnte Datei nicht schreiben"
    en="Could not write file"
    />

In code you could use it like this where you set the actual language in the message pool.

String errorMsg = ErrorMessagePool.get("couldNotOpenFileError") + additionalInformationString;

Edit: The idea of the message pool is just to wrap an existing xml parser+some additional logic.

InsertNickHere
This is a nice idea and before writing ths question it came to my mind. But... But I should attach additional code in order to parse the XML. So I thought better to ask, may be a better solution will be found out.
Narek
Probably better to have separate files for each language. Then you can send out a single file for translation.Or we built a little tool that converts it into a a CSV "english,foreign" then the translator can work on it with no special tools and without having to understand xml,rc, etc
Martin Beckett
Since the OP mentioned using Qt, he should use Qt's internationalization system (http://doc.qt.nokia.com/latest/internationalization.html).
Job
No I do not use!
Narek
+3  A: 

I would say that the strategy is extremely different between:

  • an error message for the logs
  • an error message to be presented to the user

Since you speak of internationalization, I would suppose that you need to present it to the user. In this case it's not different of any other string.

The gettext library should come in handy :)

Matthieu M.
+1 gettext for platform agnostic
Greg Domjan
A: 

This is not specific to error messages, but in terms of Qt, if you are think about internationalisation and possibly having to translate all your user facing text the Linguist Manual (Programmers Section) is a must read. I personally also favor the approach where errormessages are literal at the point where the error occurs, by using QObject::tr() whenever a free, free as in plain embedded in the code, user facing string occurs you are well on your way to keep things working and enable a later translation. tr() supports a string qualifier to mark up the text to be translated

Harald Scheirich
Why using Qt internationalization is a must? May be I have done it in a better way!
Narek
That might be, but not to sound harsh, unless there was a specific need in the qt solution that was not filled you wasted your time and money.
Harald Scheirich