Is it really necessary to include a text description when throwing a exception?

Question

As when using any other class or third party libraries, one would expect exceptions to be documented as well, so I've always found somewhat redundant to add text descriptions to them. Are they really necessary?

What are your thoughts? Thanks in advance.

Answer 1

A particular exception ought to be documented but including a text description allows you to add more context about the current instance of the exception.

In other words what good is an ArgumentException without knowing which argument is in question and what state the argument was in that triggered the exception.

Answer 2

Yes, the Message property and the message constructor parameter are required. They are not redundant.

This is the message to the developer on the other side, telling him or her what went wrong. For instance, it's not enough to throw a FileNotFoundException - you should say which file. It's not enough to say that an exception occurred while processing a web request - you should say which error, and which request.

Answer 3

It's useful to have a textual description when you want to display the result of an exception to the user (although i18n makes this a bit trickier) or when you're writing the exception to a log file. Remember, the textual description can contain more information that might be available at runtime, which is not available when documenting the exception. Things like the parameter name in an ArgumentNullException spring immediately to mind.

Answer 4

Text descriptions are very useful. There are a few reasons why I think they should always be included:

• They allow you to get a clear idea of the exception without having to look it up in docs.
• They allow more specific information to be passed than the documentation for a "generic" exception - in particular, information about the context of the exception can be included
• They allow you to internationalize your exception messages (very important)
• They provide a way (if done well) to provide more meaningful reporting to the end user, depending on the situation. However, this has to be done with care (you don't want to necessarily just show every exception to an end user, if it's a human being.)
• They provide an easy way to add exception logging that's more meaningful than just a type
• They provide standardization: The exception will meet the user's expectation of the exception, since the framework is based on having this information

Answer 5

When debugging or troubleshooting, the last thing I want to have to do is unnecessarily read through documentation. I think it is pretty handy to have explanatory text to accompany excecptions. If this wasn't provided, I think the library really missed the boat.

Answer 6

Exceptions should include as much information as is necessary to completely diagnose the problem. This almost always includes a description of the problem as simply having the type of an exception is insufficient to track down the problem.

For instance consider if the following exception's didn't include a message. Would you still be able to track down the problem

• FileNotFoundException
• Argument*Exception