Error strings should not be capitalized (unless beginning with proper nouns or acronyms) or end with punctuation, since they are usually printed following other context.
What Periods Communicate in Text Messaging. In the context of texting, other linguistic researchers have suggested that the period reads as final—as shutting down a conversation—and that it is more commonly used at the end of a sentence that is meant to convey unhappiness, anger, or frustration.
Exception messages depend on the transaction being carried out and are meant to inform you of an important or critical event (for example, start date lies in the past, safety stock has been exceeded). By means of the exception messages, you can easily sort out any materials that you need to reprocess manually.
Yes I usually treat the exception messages as full sentences, ending them with a period.
However, the message in the exception is meant for the developer, and not the end user. It may very well be that the same underlying exception should result in two different messages for the end user, depending on the context in which the exception-throwing method was called.
You really should show less technical, more user friendly messages to the user.
Q. Do you end your exception messages with a period?
From Best Practices for Exceptions† on MSDN in the section "Creating and raising exceptions":
- Use grammatically correct error messages, including ending punctuation. Each sentence in a description string of an exception should end in a period. For example, "The log table has overflowed.” would be an appropriate description string.
And regarding possible feedback to the user via the the application user interface, the question includes:
...Could also be an issue in localized resource strings.
The MSDN article referenced above also states:
- Include a localized description string in every exception. The error message that the user sees is derived from the description string of the exception that was thrown, and not from the exception class.
Also, from Exception.Message Property† at the beginning of the section "Remarks":
Error messages target the developer who is handling the exception. The text of the Message property should completely describe the error and, when possible, should also explain how to correct the error. Top-level exception handlers may display the message to end-users, so you should ensure that it is grammatically correct and that each sentence of the message ends with a period. Do not use question marks or exclamation points. If your application uses localized exception messages, you should ensure that they are accurately translated.
† .NET Framework 4.6 and 4.5
Exception messages in the framework are dot-terminated; I tend to do the same for that reason.
In any case, choose a style and try to stick to that...
I always use periods in my exception descriptions. The simple fact is that sentences which are properly punctuated are easier to read and more professional-looking, which is important for perceived quality - don't you think?
Compare it to:
i always use periods in my exception descriptions the simple fact is that sentences which are properly punctuated are easier to read and more professional looking which is important for perceived quality dont you think
Exception messages form a part of the developer interface to your application. Interfaces are generally designed with a view to helping the user perform some specific task. In the case of an exception, the interface provided should be designed to convey information about an error which has occurred within the application.
When you decide to throw an exception and write a line like
throw new ArgumentException("The string must contain at least one character.");
then you have already made a number of decisions about the interface including:
Remember, the developer interface exists to serve developers and the user interface to serve the user, the former has vastly different requirements than the latter, so what is good for one might not be good for the other, so a period in the exception message should not concern the user interface because it should not be visible to the end user.
The use of a period is not a major decision in most cases but you should consider whether its presence (or lack thereof) is beneficial or detrimental to the interface by considering points already raised including framework consistency and localisation.
I know this post is a little wordy and possibly a little astronauty, but I hope it is helpful to you.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With