Exception for missing data

I was wondering what kind of exception should one throw for missing data. For example if an xml node doesn't contain data. It would be easy to "throw new Exception(...)" but this is not recommended. Another option would be to create a new exception class like MissingDataException or InvalidDataException but isn't there a built-in exception class for this case?

As a rule of thumb, check the existing .NET framework exceptions for a suitable exception to throw before deriving your own. To answer your question directly, there is no "missing data" exception currently available to throw, but that doesn't mean there aren't suitable exceptions to cover your situation.

In your case, the humble [InvalidOperationException][1] may be suitable; this exception is thrown when you call a method on an object, but the object's state is not appropriate for the operation. Examples of this include calling methods on a closed stream and an enumerator that has passed the end of the collection. If the XML data is the internal state of an object, and a method call has discovered the bad data, [InvalidOperationException][1] is a good candidate.

If you are passing your XML data to a method, an [ArgumentException][2], or one of its derivatives may be an appropriate choice. There is a small family of these exceptions, all indicating that an argument passed to a method is not as the method expected.

You will only want to create a custom exception when you want the exceptional circumstance to be handled differently from other exceptions. If you do choose to create your own exception, be sure to derive it from a higher exception than [Exception][3], so that the nature of the exception is implied by the base class.

[1]: http://msdn.microsoft.com/en-us/library/system.invalidoperationexception.aspx "System.InvalidOperationException" [2]: http://msdn.microsoft.com/en-us/library/system.argumentexception.aspx "System.ArgumentException" [3]: http://msdn.microsoft.com/en-us/library/system.exception.aspx "System.Exception"

There is also System.Data.ObjectNotFoundException class which you may consider.

Update: As of Entity Framework 6, this exception class' fully qualified name is System.Data.Entity.Core.ObjectNotFoundException.

See this question for further details on EF5->EF6 namespace changes.

Do not call "throw new Exception", because you don't know how to handle the exception.

Define your own exception. Be more specific, such as XMLDataMissingException. Then you can give a meamingful message to user or log it.

For a general missing data scenario, where the data is referenced by a unique ID, then the KeyNotFoundException might be appropriate - e.g.

throw new KeyNotFoundException($"Expected record for key {key} not found.");

It is in the System.Collections.Generic namespace.

You can use System.Xml.XmlException.

Edit : Even if System.Xml.XmlException could fit, I think you should define your own exception, as it would be more precise, and you could describe what kind of data is missing : an id, a date, etc.

As a rule of thumb you should throw exceptions in Exceptional Circumstances. If the data in question adversely affects the object’s state or behaviour then throw a custom exception. An alternative approach might involve some kind of validator that fires events which your client handles gracefully, for example, report the error to end-user or insert default values.

I had a similar problem you described in which I had 2 clients (call them A & B) reading and modifying a single xml file. Client A deleted node X then Client B attempted to update node X. Clearly, updating a node that no longer exists is a problem. To solve this problem I took inspiration from SQL Server which reports the number of rows affected by an UPDATE statement. In this particular case I raised the UpdateNode event as normal with a number of rows affected property set to zero.

throw new Exception("my message"); (or other built in Exception) is often the correct approach. The alternative is an explosion of Exception classes that may only get used once.

If new Exceptions are warranted they should be created in the context of the domain, not the problem.