views:

487

answers:

4

Since I can't use Microsoft as an example for best practice since their exception messages are stored in resource files out of necessity, I am forced to ask where should exception messages be stored.

I figure it's probably one of common locations I thought of

  • Default resource file
  • Local constant
  • Class constant
  • Global exception message class
  • Inline as string literals
A: 

Out of necessity? It's to ease localization. To localize error messages in your applications, it's a great way.

Mehrdad Afshari
Exception messages aren't generally the same thing as user-visible error messages.
Jon Skeet
+9  A: 

I may get shot (well, downvoted) for this, but why not "where you create the exception"?

throw new InvalidDataException("A wurble can't follow a flurble");

Unless you're going to internationalize the exception messages (which I suggest you don't) do you particularly need them to be constants etc? Where's the benefit?

Jon Skeet
While it might not be OK to show error message in a local language, it's necessary for Microsoft as the platform vendor. But for many projects, I have used string literals. However, I think if you really want to store it somewhere, it'd be the resource file, not constants or other kind of stuff.
Mehrdad Afshari
By error message, I meant the Exception.Message property.
Mehrdad Afshari
That's currently where many of the messages are, but this has led to slight variations in wordings for what are essentially the same exception. Additionally sometimes the messages are very wordy which can lead to it trailing off the screen.
Orion Adrian
Orion, In that case, I think you should use different exception classes that set the message in their constructor. This will unify the messages.
Mehrdad Afshari
@Orion: When you say they're "trailing off the screen" do you mean in the user interface? Exceptions aren't designed to be user-friendly; they're designed to be *developer* friendly.
Jon Skeet
@Mehrdad: I quite agree that it makes sense for MS (and possibly library vendors) to internationalise exception messages - their consumers are the developers. That's not the case for most apps. I think we agree :)
Jon Skeet
I was referring to the IDE.
Orion Adrian
Okay, that's all right then. If your messages are too long, then try to cut them down. They don't have to be full sentences of glorious prose - just enough information to get the job done. I don't see how using a resource file would help here. Variations in wording don't matter either.
Jon Skeet
I'm staring at the top of the screen for my "Jon Skeet Agreement" gold badge. :))
Mehrdad Afshari
There seems to be a sweet spot where there's enough information to correctly diagnose the problem, but not so much that it adds to the confusion. I generally find that to be one, maybe two sentences.
Orion Adrian
@Orion: I can usually manage with a single sentence, but make sure you've got enough variables etc to diagnose it. You're likely to be able to find exactly the bit of code which threw the exception, so that gives more "static" information - it's the "dynamic" information which is important.
Jon Skeet
A: 

If you are not going to show the exception messages to the user, then you need to keep them separate from the resource strings you do need to translate.

Either use string literals like Jon suggests or create a utility class to hold them if you have a lot of duplicate strings.

Larry Fix
+1  A: 

If your exceptions are strongly typed, you don't need to worry about messages. Messages are for presenting errors to users, and exceptions are for controlling flow in exceptional cases.

throw new InvalidOperationException("The Nacho Ordering system is not responding.");

could become

throw new SystemNotRespondingException("Nacho Ordering");

In the latter case, there's nothing to translate, and therefore no need to worry about localization.

Michael Meadows