First letter of error messages should be in uppercase

[Vadim Guchenko <techmsgs@…>]

Usually error messages begin with a capital letter.

[viboes]

Replying to Vadim Guchenko <techmsgs@…>:

Usually error messages begin with a capital letter.

Please, could you be more precise?

[Vadim Guchenko <techmsgs@…>]

Consider examples/real.cpp:

s1# ./real --output
required parameter is missing in 'output'
s1# ./real --br
unknown option br

I would like the output to be:

s1# ./real --output
Required parameter is missing in 'output'
s1# ./real --br
Unknown option br

[Sascha Ochsenknecht]

You're talking about the messages/strings returned by the what() function of the related exception type. These strings are NOT meant to give an error message to user. Of course you can use them, but you don't have control over them (localisation etc.).

The use of different exception types/classes enables you to generate your own error messages which fit in your environment/application.

You catch the exception and depending on the catched type you generate an error/warning/message or whatever to the user.

The what() message can be seen as a fall-back if you don't have an appropriate handling of the related exception.

Does it make sense?

Cheers, SAscha

[Vadim Guchenko <techmsgs@…>]

Replying to s_ochsenknecht:

You're talking about the messages/strings returned by the what() function of the related exception type. These strings are NOT meant to give an error message to user. Of course you can use them, but you don't have control over them (localisation etc.).

I disagree with you. I always use text messages from exceptions and output them to the log/console, optionally adding some prefix. I examine the exception class only when I need to do some work dependent on the class. Localization is a task of the library, not of the user application. The user may only choose what locale to use.

Moreover, the same exception class is often used in different contexts to throw exceptions with different text messages. Such text messages may contain information that cannot be gotten from the exception class (for instance, the name of the option which caused a error).

The use of different exception types/classes enables you to generate your own error messages which fit in your environment/application. You catch the exception and depending on the catched type you generate an error/warning/message or whatever to the user.

Do you suggest to catch every possible exception class in the application in order to give some adapted error message to the user? That is wrong approach.

[Sascha Ochsenknecht]

At Error and Exception handling you can find a guideline on how exceptions should be used within boost libraries.

Specially point 5 says:

5. *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...

In my opinion it is quite hard to fit all user needs regarding to the messages what() produces. So, maybe the next ticket occurs which says "please, first letter should be lowercase". You get a message and you can use it, but you also have the possibility to format your own one. Its up to you.

Anyhow, this is a general topic and maybe it is something for the mailing list.

[Vladimir Prus]

The way I meant to use the 'what' text, is after printing a suitable preamble. E.g.

Error has occured: <text-from-what>

In such context, capitalization is not needed. It seems to be that prepending error messages with some preamble, even just "Error:" helps to distinguish them from other output from the program.